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

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

---

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

---

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