Home

Автор: Will Yates

Оригинальная публикация: http://www.test-talk.info/2017/02/all-our-tests-should-always-pass.html

Перевод: Анна Радионова

Такие процессы как Continuous Integration и автоматизация тестирования требуют, чтобы написанные тесты были высокого качества и всегда завершались успешно. Не скажу, что я на 100% с этим согласен. Тесты, которые всегда проходят успешно, могут скрывать недостатки продукта, тем самым снижая его качество.

В любом пайплайне CI новые билды тестируются при помощи набора автоматизированных тестов.  Такие инструменты как Chef или Jenkins хорошо справляются с организацией этих процессов и их управлением. Однако, они используют набор тестов, которые практически гарантированно  будут выполнены. Если используются одни и те же тесты и они всегда выполняются успешно, это - повод задуматься над следующими вопросами:

1. Выполняют ли тесты именно те проверки, которые вы от них ожидаете? Тестируют ли они код, тестирование которого предполагаете вы? Не может ли быть такого, что они просто исполняют код, а не тестируют его? Остерегайтесь таких тестов, которые тестируют не то, что предполагаете вы.
2. Не расположены ли тесты и новый код продукта в разных средах? Если ваши тесты направлены на проведение регрессионного тестирования части продукта, которая не связана логически с новым выпускаемым кодом, может оказаться так, что продукт тестируется не полностью.
3. Опасайтесь “пестицидного парадокса”. Если долгое время используются одни и те же тесты, скорее всего, код “приобрел иммунитет” к тестам. Фрагменты кода, которые проверяются с помощью автотестов, скорее всего, со временем стали настолько хорошо написаны и отрефакторены, что вероятность внесения разработчиком ошибки в них крайне мала.
4. Тесты устарели. При том, что автотесты выполняют разрабатываемый код, нужно учитывать, что они необязательно выполняют проверки таким же способом, каким будут взаимодействовать с продуктом ваши клиенты.  Возможно, в тестах используется неподдерживаемый способ запуска или методы, которые зарекомендовали себя не лучшим образом.

Тесты, относящиеся к вышеуказанным категориям, усыпляют вашу бдительность и создают иллюзию защищенности. Конечно, они проходят успешно, но делают ли они то, что должны? Для поддержания высокого качества ваших пайплайнов рекомендую:

1. Чередовать ваши CI тесты.  На разных этапах тестирования вы должны использовать разные тесты. Смена очередности тестов в зависимости от этапа пайплайна помогает прогнать код автотеста разными способами на разных этапах интеграции и повышает вероятность выявления и локализации дефекта.
2. Рассчитывать рейтинг эффективности тестов - отношение количества выявленных тестом регрессионных дефектов к количеству его прогонов. Существует вероятность, что неэффективные тесты некорректно проверяют код или тестирование проводится на тестовой среде, которая сконфигурирована таким образом, что на ней вряд ли можно провести полноценное регрессионное тестирование. Такие тесты есть смысл проводить по мере необходимости.
3. Добавлять в пайплайн новые тесты на регулярной основе. Написание нового теста для существующего функционала продукта является отличным тренировочным упражнением и источником выявления новых дефектов.

Подводя итог: хотя вам нужен код для успешного прохождения пайплайна в системе CI, выявление регрессионных дефектов на постоянной основе благоприятно влияет на качество продукта. Не стоит кичиться тем, что ваши тесты всегда завершаются успешно - они могут просто “замалчивать” проблемы.

Обсудить в форуме