Тестировщики компании ALG Systems начинают серию заметок по тестированию, как части процесса разработки. Это первая заметка из этой серии: в ней рассматривается, как лучше построить цикл разработки.
Мы рекомендуем построить цикл разработки следующим образом:
- Взять код из репозитория.
- Выполнить существующие тесты, чтобы убедиться, что они проходятся. Если что-то поменять в коде и потом обнаружить, что тесты выдают ошибку, можно долго искать, где проблема. Особенно, если вы взяли код уже с ошибками.
- Удалить модульные тесты для требований, которые более не действительны. Например, предположим, что требования для кода Морта поменялись так, что при вводе отрицательных чисел возвращается результат равный нулю.
Он удаляет тест ИсключениеЕслиАргументОтрицательноеЧисло, но оставляет ПростойТестПоИзвлечениюКвадратногоКорня. - Выполнять цикл:
{
a. Красный: Написать модульный тест таким образом, чтобы он не проходился.
Создать новый модульный тест:
- Для тестирования функционала, который планируется реализовать.
- Для расширения диапазона данных, используемых в тесте. Например, тестировать диапазон значений, а не только одно значение.
- Для проверки кода, который ранее не проверялся. Подробнее о покрытии кода будет сказано ниже.
Запустить тест, и убедиться, что он не проходится. Это хорошая практика, которая помогает избежать такой ошибки, как не поставленная в конце теста проверка. Ведь если тест проваливался, то когда он выполнится без ошибок, будет точно известно, что действительно есть достижения.
b. Зеленый: Изменить приложение так, чтобы тесты проходились.
Убедиться, что все, а не только новые тесты, проходятся.
c. Рефакторинг: Пересмотреть код приложения, чтобы он легко читался и изменялся.
Пересмотреть код, чтобы убедится в том, что его легко читать и изменять, и что он правильно работает. После этого опять выполните все тесты.
d. Проверить, насколько тесты покрывают код.
} до тех пор, пока большая часть кода не будет покрыта тестами, будет достигнуто соответствие всем требованиям, и все тесты выполняются успешно.
Покрытие кода
Важно знать, какая часть кода проверяется модульными тестами. Инструменты для измерения покрытия кода дают понять, какой процент кода покрыт при выполнении модульных тестов и выделяют красным не охваченный тестами код.
Низкое покрытие означает, что часть логики кода не была протестирована. Высокое покрытие не обязательно означает, что все комбинации входных данных будут правильно обработаны. Но, тем не менее, оно показывает, что вероятность правильной обработки достаточно высока. Стремитесь к покрытию в 80%.
Для того чтобы увидеть результаты покрытия, необходимо зайти в меню Unit Test и выбрать опцию Analyze Code Coverage. После выполнения тестов отобразится таблица, показывающая процент кода, который был покрыт, с распределением покрытия в каждой сборке и модуле.
Результат проверки покрытия кода
Нажмите на кнопку Coverage coloring для того, чтобы увидеть самый полезный функционал. Будут подсвечены куски кода, которые не выполнялись. Рекомендуем писать больше тестов, которые будут проверять этот неохваченный код.
Политики внесения кода (check-in)
Лучший способ поддержания сборок на сервере рабочими – это препятствовать внесению плохого кода в систему контроля версий. Политики внесения кода применяются для того, чтобы напоминать членам команды выполнять определенные действия, перед тем как вносить код. Например, политика тестирования требует, чтобы определенный набор модульных тестов выполнялся без ошибок. В дополнения к встроенным политикам, можно скачивать найденные в сети или устанавливать собственные. Более детальную информацию можно найти, на сайте MSDN в теме Enhancing Code Quality with Team Project Check-in Policies .
Пользователи могут и не следовать политикам при внесении кода. Но тогда они должны будут писать пояснительные комментарии, и такое внесение будет упомянуто в отчете.
Для того чтобы в Visual Studio настроить правила внесения кода, в меню Team нужно выбрать Team Project Settings -> Source Control. И выбрать вкладку Check-in Policy.
Добавить политику внесения кода в репозиторий
В следующей заметке мы продолжим эту тему и расскажем, как писать хорошие модульные тесты.
