Джин Ким - Руководство по DevOps

Кроме того, не только само воспроизведение ошибок, обнаруженных в ходе интеграционного тестирования, является трудоемким и отнимает много времени. Сложным является даже процесс проверки того, что они действительно исправлены (то есть разработчик создает исправление, но затем необходимо ждать четыре часа, чтобы узнать, успешно ли завершилось интеграционное тестирование).

Поэтому, обнаружив ошибку в ходе приемочного или интеграционного тестирования, мы должны создать модульный тест, чтобы он мог найти ошибку быстрее, раньше и дешевле. Мартин Фаулер описал понятие «пирамиды идеального тестирования». С ее помощью мы могли бы отлавливать большинство ошибок благодаря модульным тестам (рис. 14). На деле же зачастую верно обратное, и основной вклад в поиск ошибок вносят ручное и интеграционное тестирование.

Идеальное и неидеальное автоматизированное тестирование

Рис. 14. Пирамиды идеального и неидеального автоматизированного тестирования (источник: Martin Fowler, TestPyramid)

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

Поскольку мы хотим, чтобы наши тесты выполнялись быстро, нам необходимо разработать их так, чтобы они могли работать параллельно и потенциально — на большом количестве разных серверов. Нам также может понадобиться выполнять тесты различных категорий параллельно. Например, когда сборка проходит приемочные тесты, мы можем запускать тесты производительности и одновременно — тесты безопасности, как показано на рис. 15. Мы можем допускать или не допускать исследовательское тестирование вручную до завершения всех автоматических проверок — если допускаем, это позволит раньше получить обратную связь, но может привести к затратам времени на сборки, не прошедшие автоматизированное тестирование.

Рис. 15. Параллельный запуск автоматизированных тестов и тестирования вручную (источник: Джез Хамбл, Дэвид Фарли «Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ» [82])

Любую сборку, прошедшую все наши автоматизированные тесты, мы делаем доступной для исследовательского тестирования, равно как и для других форм ресурсоемкого тестирования (вручную, например тестирование производительности). Мы хотим проводить такие тесты настолько часто, насколько возможно — либо непрерывно, либо по расписанию.

Любой, кто тестирует (включая и всех наших разработчиков), должен использовать самую последнюю сборку, прошедшую все автоматизированные тесты, а не ожидать, пока разработчики пометят конкретную сборку как готовую к тестированию. При этом мы можем обеспечить, чтобы процесс тестирования начался как можно раньше.

Один из наиболее эффективных путей обеспечения надежными автоматизированными тестами — написание тестов в ходе повседневной деятельности с использованием таких методов, как «разработка через тестирование» (TDD — test-driven development) и «разработка через приемочное тестирование» (ATDD — acceptance test-driven development). При использовании этих методов мы начинаем любое изменение в системе с того, что пишем автоматизированный тест, проверяющий, не будет ли сбоев в ожидаемом поведении кода, и лишь затем пишем код, который будет проходить эти тесты.

Этот метод был разработан Кентом Беком в конце 1990-х гг. как часть его концепции экстремального программирования и состоит из трех шагов.

1. Убедиться, что тест не пройден. «Напишите тест для проверки следующего кусочка функциональности, который вы хотите добавить». Запишите эти изменения.

2. Убедиться, что тест пройден. «Пишите функциональный код, пока тест не начнет успешно проходить». Запишите эти изменения.

3. Выполните рефакторинг как старого, так и нового кода, чтобы обеспечить его хорошую структурированность. Убедитесь, что тест успешно проходит. Снова запишите изменения кода.

Наборы автоматизированных тестов фиксируются в системе контроля версий наряду с нашим кодом, что обеспечивает документированность текущего состояния нашей системы. Разработчики, желающие понять, как использовать систему, могут обратиться к этим наборам тестов, чтобы найти рабочие примеры использования системных API [83].

Наша цель — найти как можно больше ошибок в коде с помощью наборов автоматизированных тестов, снижая зависимость от тестирования вручную. В своей презентации «В заботе о циклах обратной связи и их поддержании» (On the Care and Feeding of Feedback Cycles) на конференции Flowcon в 2013 г. Элизабет Хендриксон отмечала: «Хотя тестирование может быть автоматизировано, создание качества автоматизировать невозможно. Выполнение вручную тестов, нуждающихся в автоматизации, — пустая трата человеческого потенциала».

При этом мы даем возможность всем нашим тестировщикам (разумеется, включая разработчиков) заниматься деятельностью, имеющей высокую ценность. Она не может быть автоматизирована: это аналитическое тестирование или улучшение самого процесса тестирования.

Однако простая автоматизация всех тестов, проводящихся вручную, может дать нежелательные результаты, ведь мы не хотим, чтобы автоматизированные тесты были ненадежны или давали ложно-положительный результат (то есть тесты должны быть проходимыми, только если код правильно функционирует, но должны сообщать о сбоях, если возникнут проблемы: низкая производительность, задержки при выполнении, неконтролируемое начальное состояние или непредусмотренное состояние из-за использования заглушек баз данных либо общих сред тестирования).

Ненадежные тесты, генерирующие ложные срабатывания, создают значительные проблемы — они отнимают драгоценное время (например, вынуждая разработчиков повторно запускать тест, чтобы определить, существует ли проблема на самом деле), увеличивают общее количество усилий, требующихся для запуска тестирования и интерпретации его результатов. Зачастую они же приводят к стрессовым нагрузкам на разработчиков; те начинают полностью игнорировать результаты тестов или выключают автоматическое тестирование и сосредоточиваются на создании кода.