 ПОЗНАВАТЕЛЬНОЕ Сила воли ведет к действию, а позитивные действия формируют позитивное отношение Как определить диапазон голоса - ваш вокал Игровые автоматы с быстрым выводом Как самому избавиться от обидчивости Противоречивые взгляды на качества, присущие мужчинам Вкуснейший "Салат из свеклы с чесноком" Натюрморт и его изобразительные возможности Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д. Как научиться брать на себя ответственность Зачем нужны границы в отношениях с детьми? Световозвращающие элементы на детской одежде Как победить свой возраст? Восемь уникальных способов, которые помогут достичь долголетия Классификация ожирения по ИМТ (ВОЗ) Глава 3. Завет мужчины с женщиной
Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.
| Лабораторная работа №3. Юнит тестирование.
1 Цель работы
Получение навыков разработки юнит-тестов и проведения тестирования программного обеспечения.
2 Задание
Создать набор юнит тестов для двух функций. Функции, для которых создаются юнит тесты, необходимо согласовать с преподавателем.
3 Теоретический материал 3.1 Теория юнит тестирования
Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок. Цель модульного тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны. Этот тип тестирования обычно выполняется программистами. Модульное тестирование позже позволяет программистам проводить рефакторинг, будучи уверенными, что модуль по-прежнему работает корректно (регрессионное тестирование). Это поощряет программистов к изменениям кода, поскольку достаточно легко проверить, что код работает и после изменений. Модульное тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируя отдельные части программы, а затем программу в целом. Модульные тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера. Поскольку некоторые классы могут использовать другие классы, тестирование отдельного класса часто распространяется на связанные с ним. Например, класс пользуется базой данных; в ходе написания теста программист обнаруживает, что тесту приходится взаимодействовать с базой. Это ошибка, поскольку тест не должен выходить за границу класса. В результате разработчик абстрагируется от соединения с базой данных и реализует этот интерфейс, используя свой собственный mock-объект. Это приводит к менее связанному коду, минимизируя зависимости в системе. Тестирование программного обеспечения — комбинаторная задача. Например, каждое возможное значение булевской переменной потребует двух тестов: один на вариант TRUE, другой — на вариант FALSE. В результате на каждую строку исходного кода потребуется 3−5 строк тестового кода. Как и любая технология тестирования, модульное тестирование не позволяет отловить все ошибки программы. В самом деле, это следует из практической невозможности трассировки всех возможных путей выполнения программы, за исключением простейших случаев. При выполнении юнит-тестов происходит тестирование каждого из модулей по отдельности. Это означает, что ошибки интеграции, системного уровня, функций, исполняемых в нескольких модулях, не будут определены. Кроме того, данная технология бесполезна для проведения тестов на производительность. Таким образом, модульное тестирование более эффективно при использовании в сочетании с другими методиками тестирования. Для получения выгоды от модульного тестирования требуется строго следовать технологии тестирования на всём протяжении процесса разработки программного обеспечения. Нужно хранить не только записи обо всех проведённых тестах, но и обо всех изменениях исходного кода во всех модулях. С этой целью следует использовать систему контроля версий ПО. Таким образом, если более поздняя версия ПО не проходит тест, который был успешно пройден ранее, будет несложным сверить варианты исходного кода и устранить ошибку. Также необходимо убедиться в неизменном отслеживании и анализе неудачных тестов. Игнорирование этого требования приведёт к лавинообразному увеличению неудачных тестовых результатов.
3.2 Среда Nunit.
NUnit – открытая среда юнит-тестирования приложений для .NET, которая позволяет создавать автоматические тесты. Nunit легко интегрируется с другими средствами разработки ПО, тесты NUnit можно запустить из консоли, графической оболочки, скрипта сборки, или любым другим программным способом.
3.2.1 Интеграция с MS Visual Studio
Сначала необходимо скачать NUnit с сайта [5]. Затем необходимо разархивировать и запустить установщик программы. Существует по меньшей мере два способа использования NUnit. В данном пособии описано добавление NUnit как внешнего инструмента и запуск тестов NUnit при отладке роекта в Visual Studio. Для того, чтобы интегрировать NUnit в Visual Studio, необходимо добавить его как внешний нструмент. Для этого в меню «Tools» необходимо выбрать пункт «External Tools». В появившемся окне необходимо указать: - Title: название пункта меню, например, NUnit. - Command: Путь до графического интерфейса NUnit, например, C:\Program Files (x86)\NUnit 2.5.3\bin\net-2.0\nunit.exe. - Arguments: Аргументы передаваемые приложению, т.е. путь до сборки, например, $(ProjectDir)bin/Debug/$(TargetName)$(TargetExt). - Initial directory - Рабочая папка - $(TargetDir). После этого, если выбрать проект с тестами и выбрать в меню Tools пункт NUnit, стартует графическая оболочка программы. Для того, чтобы тесты запускались при запуске отладки проекта, необходимо настроить запуск NUnit в свойствах проекта (вкладка Debug). Необходимо найти вкладку «Start external program»(запускать внешнюю программу) и задать путь до NUnit, например, C:\Program Files (x86)\NUnit 2.5.3\bin\net-2.0\nunit.exe. Далее, во вкладке Command line arguments необходимо задать путь до файла настроек NUnit и категорию для автозапуска, например, файл настроек ..\..\NunitTests.nunit и категория /include:Debug /runselected (разделяются пробелом). В папке проекта необходимо создать файл с названием NunitTests.nunit со следующим содержанием(название сборки необходимо заменить на свое): <NUnitProject> <Settings activeconfig="Debug" /> <Config name="Debug"> <assembly path="bin\Debug\[название сборки].dll" /> </Config> <Config name="Release"></Config> </NUnitProject> В дальнейшем, тесты, которые необходимо запускать при отладке, отмечаются аттрибутом [Test, Category(«Debug»)].
3.2.2 Разработка тестов
Сначала необходимо создать проект библиотечного класса. Для этого, неободимо выбрать пункт меню «File -> New -> Project», в открывшемся окне выбрать Visual C # в установленных шаблонах и выбрать тип приложения «Class library». После этого необходимо задать название проекта и нажать «OK». В результате созданный проект появится в Solution Explorer (в правом верхнем углу Visual Studio).
Рисунок 6 – Окно создания проекта
Далее необходимо добавить ссылку на NUnit в проект. Для этого необходимо кликнуть правой кнопкой мыши на ссылку, выбрать «Add reference -> Browse », затем nunit.framework.dll и «OK». Далее необходимо создать тестовый класс. Для этого необходимо кликнуть правой кнопкой мыши на проекте, выбрать Add -> Class, ввести имя и нажать кнопку "Add".
Рисунок 7 – Окно добавления класса
После этого отобразится созданный класс.
Рисунок 8 – Код только что созданного тестового класса
В код необходимо добавить сторку using NUnit.Framework; При написании кода тестового класса неободимо соблюдать некоторые условия: - Каждый класс должен содержать атрибут [TestFixure] и должен быть общедоступен. - В каждом методе должен присутствовать атрибут [Test]. - Оператор подтверждения об отсутствии ошибок: Булевские значения, описывающие, что должно быть ключевым словом, когда выполняется действие. - Ожидаемое исключение: один из типов исключения, который мы ожидаем во время выполнения тест-метода. - Установка: программа, которая запускается перед выполнением каждого тест-метода (например, регистрация в системе конкретного пользователя или инициализация одноэлементных классов). - Демонтаж: программа, запускается после окончания каждого тест-метода (например, удаление строк из таблицы, которые были вставлены во время теста).
Рисунок 9 – Пример кода тестового класса
3.2.3 Запуск тестов
После написания всех тестов в тестовом классе, необходимо запустить тесты, чтобы проверить, проходят ли они успешно. Для запуска тестов нужно перейти в папку NUnit, выбрать NUnit Application (.exe) и дважды кликнуть по ней, затем выбрать команду File-> Open Project, выбрать проект, затем кликнуть Run.
Рисунок 10 – Главное окно программы NUnit
Рисунок 3.6 – Запуск тестов в NUnit.
После запуска тестов отобразится количество тестов, которые не сработали и количество невыполненных тестов. Для запуска определенного теста, необходимо кликнуть по нему правой кнопкой мыши и выбрать Run test(s). Более подробно работа с NUnit описана в статье [6].
|
