Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

У основания пирамиды располагаются модульные тесты. Они пишутся программистами для программистов на языке программирования системы. Целью этих тестов является определение спецификации системы на самом нижнем уровне. Выполнение тестов в контексте непрерывной интеграции помогает проследить за тем, что исходные намерения программистов были успешно реализованы.

Рис. 8.1.Пирамида автоматизации тестирования

Модульные тесты должны обеспечивать покрытие кода, настолько близкое к 100 %, насколько это возможно. В общем случае покрытие должно превышать 90 %, причем оно должно быть реальным – в отличие от фальшивых тестов, которые выполняют код без проверки утверждений относительно его поведения.

В эту категорию входит часть приемочных тестов, упоминавшихся в прошлой главе. Обычно эти тесты пишутся для отдельных компонентов системы. В компонентах системы инкапсулируются бизнес-правила, поэтому тесты компонентов становятся приемочными тестами для бизнес-правил.

Как показано на рис. 8.2, компонентный тест изолирует отдельный компонент системы. Он передает компоненту входные данные, получает от него результаты и проверяет их на соответствие входным данным.

Рис. 8.2.Компонентный приемочный тест

Для изоляции остальных компонентов системы применяются макеты и тест-дублеры.

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

Компонентные тесты обеспечивают покрытие примерно половины системы. Они в основном ориентированы на «оптимистичные» ситуации и наиболее очевидные граничные условия, исключения и аномальные ситуации. Подавляющее большинство «пессимистичных» ситуаций покрывается модульными тестами, и на уровне компонентных тестов они не имеют смысла.

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

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

Рис. 8.3.Интеграционный тест

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

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

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

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