Тесты проверки сборки иногда называют повторяющейся сборкой или ночной сборкой. Разумеется, название появилось не случайно. Сервис сборки, по расписанию (а иногда вообще непрерывно), компилирует и тестирует софт с изменениями, внесенными в систему контроля версий. Если тест проваливается, или (что еще хуже) исходный код не компилируется — сервис рассылает письма всем членам команды.
Да, существует система контроля версий, которая помогает членам команды избежать перезаписи работы друг друга и позволяет большой команде работать над единым кодом программы. После установки TFS и создания проекта для команды, с помощью Visual Studio можно создать дерево кода, добавлять в него код и выдавать разрешения на работу другим пользователям.
Но ведь хочется быть уверенным, что код делает то что от него ожидают, и для этого необходимо настроить регулярные сборки. Обычно создается несколько конфигураций: непрерывные (повторяющиеся) сборки выполняют большинство модульных тестов; и ночные сборки, которые выполняют более широкий и глубокий спектр тестов, включая тесты производительности, нагрузочное тестирование и автоматизированные системные тесты (о которых мы расскажем в следующих заметках).
Профессиональные тестировщики знают, что единственный способ поставлять качественное ПО вовремя, это никогда не вносить в репозиторий код, который недостаточно покрыт тестами; выполнять тесты на протяжении всей разработки; и никогда не оставлять ошибки неисправленными. Наверняка все, у кого есть хотя бы небольшой опыт в разработке ПО знают о проектах, в которых под конец накапливалось много не протестированного кода, и представляют, сколько проблем это потом вызывало.
Поэтому предлагаем детальный набор правил, как грамотно править исходники кода:
- Вносить в систему контроля версий все сделанные изменения в коде минимум раз в неделю, а лучше еще чаще. Планировать свои задачи по разработке таким образом, чтобы при каждом внесении кода добавлялся, пусть маленький, но готовый функционал или улучшение системы.
- Перед внесением изменений, выполнить команду Get Latest Version (в меню быстрого доступа проекта в Solution Explorer), чтобы интегрировать изменения, сделанные другими членами команды. Пересобрать все и выполнить модульные тесты.
- Использовать команду Run All Impacted Tests, которая определит, какие тесты были затронуты изменениями и выполнит их. (Более подробно в теме Streamline Testing Process with Test Impact Analysis на сайте MSDN.) Изменения, сделанные одним человеком, могут влиять на тесты, написанные кем-то другим.
Для того, чтобы иметь возможность использовать эту возможность, необходимо при выписке кода из репозитория создать базу для последующего анализа. (Тема How to: Identify the Test Impact of Code Changes During Development на сайте MSDN).
- Включить Code Coverage и проверить, что как минимум 80% кода выполняется при тестировании. Если проверок недостаточно, с помощью функционала подсветки можно увидеть, какой код не был охвачен. И написать больше тестов.
- Не вносить изменения, пока не было достигнуто покрытие кода минимум 80% и все тесты успешно проходятся. К этому правилу нужно подходить осмысленно, в некоторых случаях допустимо и более низкое покрытие. Например, при генерации кода, иногда разумно считать покрытие одно сгенерированного элемента подтверждением покрытия и другого. Но при любых исключениях необходимо, чтобы другой член команды, желательно настроенный скептически, оценил предложенное исключение из правил. Чтобы правило соблюдалось, можно создать политику тестирования внесенного кода.
- Если после внесения кода повторяющаяся сборка ломается, все получат уведомление по электронной почте. Член команды, код которого может быть источником возникшей проблемы, должен отменить внесение своего кода. И до работы над любым другим кодом, исправить ошибки и внести в репозиторий исправленную версию. Если на исправление понадобится время, нужно переоткрыть задачу, связанную с изменением – задача не может считаться выполненной, пока все не будет работать как надо.
- Не стоит убегать домой сразу после того, как код был внесен. Ведь утром почтовые ящики всех членов команды могут быть полны писем о том, что сборки были не успешными.
Вышесказанное неприменимо, если команда использует промежуточные внесения кода – изменения не интегрируется в основное тело кода до тех пор, пока все тесты не будут пройдены на вспомогательном сервере сборки.
