Как протестировать приложение visual studio
В данной теме описывается пошаговый процесс создания простейшего Unit-теста в системе Microsoft Visual Studio 2010 (C++) для приложения типа CLR Console Application . Используя данный пример, можно научиться создавать собственные Unit-тесты. Пример также демонстрирует использование класса Assert для проведения тестирования работы функций.
Содержание
- Условие задачи
- Выполнение
- 1. Создать приложение по шаблону CLR Console Application
- 2. Реализация функции Max()
- 3. Текст программы, которую нужно протестировать
- 4. Создание теста
- 4.1. Добавление нового проекта к решению
- 4.2. Структура решения
- 4.3. Текст файла теста «UnitTest1.cpp» . Атрибуты [TestMethod] и [TestClass]
- 4.4. Выполнение изменений в тексте модуля UnitTest1
- 4.5. Подключение модуля «MaxApp.cpp» проекта MaxApp к проекту TestMaxApp
- 4.5.1. Способ 1. Подключение с заданием полного имени
- 4.5.2. Способ 2. Подключение с заданием сокращенного имени
Поиск на других ресурсах:
Условие задачи
Для приложения типа CLR Console Application необходимо разработать Unit-тест, который тестирует работу функции Max3() , определяющей максимальный элемент из трех чисел. Числа функция получает входными параметрами.
Для функции Max3() установить метод тестирования TestMax() . Проверить работу функции.
Выполнение
1. Создать приложение по шаблону CLR Console Application
После запуска Microsoft Visual Studio нужно выбрать
В результате откроется окно New Project (рисунок 1), в котором нужно выбрать шаблон
Рис. 1. Создание приложения по шаблону CLR Console Application
После выбора OK, будет создано приложение типа CLR Console Application .
После создания приложения, окно текстовой части Microsoft Visual Studio будет иметь приблизительный вид, как показано на рисунке 2.
Рис. 2. Вид приложения после создания
2. Реализация функции Max()
Перед объявлением функции main() вводится текст функции Max() , который имеет следующий вид:
Именно эту функцию нужно будет протестировать с помощью Unit -теста в Microsoft Visual Studio .
3. Текст программы, которую нужно протестировать
На данный момент текст программы, которую нужно протестовать, имеет вид:
Поскольку, эта программа будет тестироваться из другого модуля тестирования, то в функции main() большее ничего вводить не нужно. Так как, в соответствии с условием задачи, нужно протестовать работу функции Max() . А это уже будет осуществляться из модуля тестирования. На данный момент наша программа готова к тестированию.
4. Создание теста
Тест создается отдельным проектом ( Project ) в решении ( Solution ). Программа, которая будет тестироваться не знает об этом. Программа-тест, которая будет тестировать вызывает функции тестируемой программы. В нашем случае программа-тест будет вызывать функцию
4.1. Добавление нового проекта к решению
Для создания теста нужно создать новый проект в решении (Solution). Для этого в Visual Studio вызывается последовательность команд
Рис. 4. Текст модуля UnitTest1.cpp. Окно утилиты Solution Explorer с отображенными проектами TestMaxApp и MaxApp
4.2. Структура решения
Как видно из рисунка 4, утилита Solution Explorer отображает структуру решения ( Solution Items ), которое содержит два проекта:
- проект MaxApp . Это проект, созданный по шаблону CLR Console Application с функцией Max() , которую нужно протестовать;
- проект TestMaxApp . Этот проект предназначен для тестирования функций проекта MaxApp . Программный код, который будет тестировать функцию Max() , будет вноситься в файл проекта UnitTest1 проекта TestMaxApp .
Оба проекта могут выполняться независимо друг от друга.
Листинг файла UnitTest1.cpp , сформированный MS Visual Studio, следующий:
Как видно из вышеприведенного кода, файл содержит класс с именем UnitTest1 . В классе есть общедоступный (public) метод с именем TestMethod1() . Перед реализацией метода TestMethod1() размещается атрибут [TestMethod] . Это значит, что в тело метода нужно вписать код, который будет тестировать функции проекта MaxApp .
В классе можно вписывать любое количество методов, которые будут тестировать разные функции из разных модулей. Главное, чтобы эти методы были помечены атрибутом [TestMethod] . Например, если нужно добавить второй метод тестирования с именем MySecondTestMethod() , то в тело класса нужно вписать приблизительно следующий код:
Аналогично, перед классом UnitTest1 размещается атрибут [TestClass] . Это означает, что в классе есть тестирующие методы.
4.4. Выполнение изменений в тексте модуля UnitTest1
Допускается изменять названия методов и добавлять новые методы, которые помечены атрибутом [TestMethod] в модуле UnitTest1.cpp . Учитывая это, в тексте модуля UnitTest1.cpp метод TestMethod1() необходимо переименовать на TestMax() .
После выполненных изменений, сокращенный текст модуля файла UnitTest1.cpp будет иметь вид:
Существует 2 способы такого подключения:
В данной теме описываются оба способа.
4.5.1. Способ 1. Подключение с заданием полного имени
Этот способ более упрощенный. Он есть удобным, когда нужно подключить в проект небольшое количество файлов для тестирования.
Здесь указывается полное имя на диске файла MaxApp.cpp , в котором размещается функция Max() , которую нужно протестировать.
4.5.2. Способ 2. Подключение с заданием сокращенного имени
Этот способ эффективен, когда нужно протестовать несколько модулей разных проектов. Подключается целый каталог (папка) с файлами тестируемого проекта.
В нашем случае нужно подключить папку:
в перечень ссылок на сборки (проекты), которые автоматически подключаются к проекту TestMaxApp . После этого, можно будет подключать модуль MaxApp.cpp по сокращенному имени
избегая использования длинного имени как показано в пункте 4.5.1.
Рис. 5. Вызов окна просмотра ссылок на сборки, которые используются в проекте TestMaxApp
Рис. 7. Окно Add Reference с отображенными проектами в текущем решении
После выбора на OK происходит возврат в предыдущее окно, в котором в перечне ссылок на сборки будет отображена ссылка на проект MaxApp .
Чтобы сделать это, нужно сначала активировать строку
как показано на рисунке 9.
После выбора, окно Include Directories будет иметь вид как показано на рисунке 11.
Рис. 11. Окно Include Directories после выбора папки E:\Test\MaxApp\MaxApp
Для перехода к предыдущему окну нужно выбрать OK .
Для перехода к написанию программного кода тестирования нужно выбрать OK.
После выполненных действий, все файлы из папки
можно подключать по сокращенному имени, например:
4.6. Написание программного кода для проведения тестирования в методе TestMax()
В вышеприведенном коде вызывается функция AreEqual() из класса Assert . Эта функция сравнивает значение, которое было возвращено из функции Max() и число 6. В данном случае, происходит сравнение числа 7 (максимум) с числом 6. Для такого варианту тест не будет выполняться, так как 7 не равняется 6. В результате функция Assert::AreEqual() выбросит исключительную ситуацию (exception), что будет отображаться в специальном окне (см. п.5).
5. Запуск теста на выполнение и проверка результата тестирования
В Microsoft Visual Studio для работы с Unit-тестами реализовано специальное меню команд, которое называется Test .
Чтобы запустить тест на выполнение, нужно выбрать одну из команд
как изображено на рисунке 13.
Рис. 13. Вызов команды запуска тестирования и просмотр результата
После запуска теста, результат можно просмотреть в нижней части в окне Test Results . Как видно, тест не сдан. Это логично, поскольку в функции Assert::AreEqual() мы сравниваем числа 6 и 7, которые различны между собой. Здесь специально введено число 6 вместо числа 7.
Если вместо числа 6 ввести правильный ответ – число 7 (максимум между 5, 6, 7), то тест будет сдан. В этом случае текст метода TestMax() будет следующей:
Окно результата изображено на рисунке 14.
Рис. 14. Результат тестирования для случая, если ввести правильную проверку
Теперь можно сделать вывод о том, что функция Max() разработана правильно
6. Текст модуля UnitTest1
7. Итог. Взаимодействие между проектами
В данной работе в решении (Solution) сформированы два проекта. Один проект MaxApp содержит функцию Max() которую нужно протестировать. Второй проект TestMaxApp содержит методы, которые тестируют.
В Microsoft Visual Studio каждый из проектов запускается с помощью различных команд меню. Так, проект MaxApp запускается стандартным способом из меню Run . А тестирующий проект TestMaxApp запускается из специального меню Test .
Поэтому возникает необходимость как-то это тестирование автоматизировать, хотя бы частично. Автоматизация такого процесса заключается в том, что приходится помимо программы, которая решает бизнес-задачу, писать ещё программу для тестирования.
Для чего это всё нужно? Представим ситуацию: вы написали сложную программу, которая содержит множество классов. Вы всё проверили о оттестировали. Возникла необходимость внести изменения в какой-то класс. После таких изменений может возникнуть ситуация, что программа вдруг перестаёт работать корректно на каком-то шаге (при добавлении нового функционала перестаёт работать старый). В данном случае, если у вас есть тестовые методы, можно их запустить и проверить работоспособность. Таким образом тестирование предотвращает появление данных проблем и позволяет быстро проверить работоспособность.
В состав Visual Studio входит модульное тестирование.
Такое тестирование отдельных частей программы, называется unit-тестированием (модульное тестирование) .
Задача состоит в том, чтобы написать дополнительный класс с методами, который будет тестировать наши основные классы.
Как создать модули-тестирования?
Добавим новый проект в наш "Solution". Воспользуемся мастером, который входит в состав "Visual Studio". Шаблон проекта: "Unit Test Project" (Проект модульного теста). Имя проекта укажем "MyTest":
Отличие от обычно класса заключается в том, что здесь присутствуют атрибуты "TestClass" и "TestMethod":
Эти 2 атрибута навешены для того, чтобы компонент NUnit (компонент Visual Studio) , когда мы захотим запустить тесты, понял где эти тесты находятся.
В этом тестовом проекте необходимо добавить ссылку ("Add reference") на основной проект, также добавить ссылку на основной проект, используя using.Что является пройденным и непройденным тестированием?
Если метод нормально закончил работу, значит тест считается пройденным. Если было выброшено любое исключение, то тест считается непройденным. Исключения можно выбрасывать самим. Также можно использовать методы класса "Assert".Например, у данного класса есть метод "AreEqual()". Он сравнивает то, что ожидаем получить с тем, что получилось по факту.
Обычно эти атрибуты используются при сложном тестировании. Для чего они могут быть нужны? Допустим перед началом тестирования вам нужно поместить какие-то тестовые данные в базу данных, либо какой-нибудь файл. После окончания тестирования то содержимое, которое мы добавили для этой базы или файла, нужно удалить.
Давайте напишем простой пример.
Напишем класс "Room"
Класс для тестирования:
Если мы теперь запустим тестирование, то выйдет ошибка тестирования (на скриншоте):
В данной статье вы немного узнали про модульное тестирование в Visual Studio, а также как его запускать.
Пусть вас не вводит в заблуждение простота данного примера, на самом деле код для тестирования занимает гораздо больше строк. Его количество зависит от того функционала, который вы хотите протестировать.
На связи был Алексей Гулынин, оставляйте свои комментарии, увидимся в следующих статьях.
Расширение возможностей программного обеспечения и как следствие усложнение его архитектуры привело к тому, что возросли также сложность объём работы по его тестированию. В результате этого возникла необходимость автоматизации процесса тестирования. Чтобы программисту или тестировщику при каждой итерации не приходилось в очередной раз выполнять одни и те же действия по проверке правильности работы программы.
В качестве одного из вариантов решения данной задачи можно рассматривать модульное или Unit тестирование.
Идея модульного тестирования состоит в том, что параллельно основному компоненту программы, который включает непосредственно алгоритмы её работы, создаётся дополнительный «тестовый», в котором имитируется работа основного компонента в тех или иных условиях. По результатам выполнения «тестового» компонента судят о правильности работы основного.
При этом «тестовый» компонент можно запускать на выполнение, не компилируя программу целиком, в том числе в автоматическом режиме. Это обеспечивает достаточно высокую степень автоматизации процесса тестирования и значительно сокращает время на его выполнение.
Важно отметить, что задача автоматизации тестирования в принципе не может быть решена полностью. В частности невозможно автоматизировать исследовательское тестирование [1]. Однако автоматизировать рутинные операции, например, интеграционное и регрессионное тестирование можно вполне. Последнее особенно важно, так как при создании новой версии программного обеспечения значительный объём работ по тестированию состоит именно в том, чтобы убедиться, что новый функционал не привёл к ошибкам в работе уже существующего.
Что собой представляет модульный (Unit) тест
Как уже говорилось выше, модульный тест это вспомогательный компонент программы, предназначенный для имитации её работы в целях тестирования. По сути, это не что иное, как программный сценарий, который вызывает те или иные функции тестируемой программы и анализирует результаты их работы.
В настоящее время для создания подобных сценариев нет необходимости разрабатывать какие-либо сложные технические решения. Существует масса готовых фреймворков, которые не только облегчают разработку тестов, но и берут на себя значительную часть работы по анализу и представлению их результатов.
Подобные фреймворки часто входят в состав интегрированных сред разработки (IDE). Собственный фреймворк для модульных тестов имеет и Visual Studio.
Для его использования в разделе «Тест» окна создания нового проекта есть специальный шаблон под названием «Проект модульного теста».
Что собой представляет данный шаблон?
При создании проекта модульного теста создаётся обычный класс, но:
- Как сам класс, так и его методы помечаются специальными атрибутами TestClass и TestMethod соответственно.
Данные атрибуты сообщают компилятору о том, что это класс модульного теста и тестовые методы. - Методы класса должны быть открытыми (public) и иметь тип void.
Класс модульного теста может включать и вспомогательные члены, но лучше всего всё, что связано с процессом тестирования располагать в тестовых методах.
Тестовые методы предназначены для реализации непосредственно процесса тестирования. Для проведения тестирования класс модульного теста должен включать как минимум один тестовый метод.
Сценарии тестирования, реализуемые внутри тестовых методов, могут быть произвольными, но лучше всего всё-таки для каждого тестового случая создавать отдельный тестовый метод.
Тест считается не пройденным (в работе программы присутствует ошибка), если в ходе выполнения тестового метода возникло исключение.
Уроки программирования, алгоритмы, статьи, исходники, примеры программ и полезные советы
Модульное тестирование в Visual Studio
Создание проекта программы, модули которой будут тестироваться
Разработаем проект содержащий класс, который вычисляет площадь прямоугольника по длине двух его сторон.
Class1 переименуем в Geometry.
В классе реализуем метод, вычисляющий площадь прямоугольника. Для демонстрации остановимся на работе с целыми числами. Код программы приведён ниже.
Площадь прямоугольника, как известно, это произведение двух его сторон.
Создание проекта для модульного тестирования в Visual Studio
Чтобы выполнить unit-тестирование, необходимо в рамках того же самого решения создать ещё один проект соответствующего типа.
Перед Вами появится следующий код:
using Microsoft . VisualStudio . TestTools . UnitTesting ;Директива [TestMethod] обозначает, что далее идёт метод, содержащий модульный (unit) тест. А [TestClass] в свою очередь говорит о том, что далее идёт класс, содержащий методы, в которых присутствуют unit-тесты.
В соответствии с принятыми соглашениями переименуем класс UnitTest1 в GeometryTests.
Также в коде необходимо подключить с помощью директивы using следующее пространство имён:
Займёмся написание теста. Проверим правильно ли вычисляет программа площадь прямоугольника со сторонами 3 и 5. Ожидаемый результат (правильное решение) в данном случае это число 15.
Тестирующий метод обычно содержит три необходимых компонента:
- исходные данные: входные значения и ожидаемый результат;
- код, вычисляющий значение с помощью тестируемого метода;
- код, сравнивающий ожидаемый результат с полученным.
Соответственно тестирующий код будет таким:
using Microsoft . VisualStudio . TestTools . UnitTesting ;Для сравнения ожидаемого результата с полученным используется метод AreEqual класса Assert. Данный класс всегда используется при написании unit тестов в Visual Studio.
В студии появится следующее окно:
Синяя табличка с восклицательным знаком означает, что указанный тест никогда не выполнялся. Выполним его.
Зелёный кружок с галочкой означает, что модульный тест успешно пройден: ожидаемый и полученный результаты равны.
Изменим код метода RectangleArea, вычисляющего площадь прямоугольника, чтобы сымитировать провал теста и посмотреть, как поведёт себя Visual Studio. Прибавим к возвращаемому значению 10.
Как Вы видите, красный круг с крестиком показывает провал модульного теста, а ниже указано, что при проверке ожидалось значение 15, а по факту оно равно 25.
Вы можете скачать исходник решения по ссылке ниже или перейти в репозиторий данного проекта на GitHub:
Приведём правило, которым следует руководствоваться при написании и проведении тестов для оценки правильного функционирования программ.
Удобнее всего будет рассмотреть пример основанный на математике.
Так или иначе тестируемый метод или функция (или вся программа в целом) имеет свою область допустимых входных значений. Для проверки правильности работы метода достаточно провести тестирование метода на входных значениях начала и конца области допустимых значений (ОДЗ), одного значения из внутренней части области, а также -1 от левой и +1 от правой границы области.
Читайте также: