Интеграционные тесты обычно пишутся системными архитекторами (или ведущими проектировщиками) системы. Они проверяют основательность архитектурной структуры системы. Именно на этом уровне обычно встречаются тесты производительности и пропускной способности.
Компонентные тесты пишутся специалистами по контролю качества и бизнес-стороной при помощи разработчиков. Они формируются в средах компонентного тестирования – таких как FitNesse, JBehave или Cucumber. (Компоненты графического интерфейса тестируются в специализированных средах вроде Selenium или Watir.) Тесты должны быть написаны так, чтобы бизнес-сторона могла читать и интерпретировать их (или даже
Очень важно, чтобы тесты непрерывной интеграции все время проходили успешно. Они никогда не должны завершаться отказом. В случае отказа вся группа прекращает заниматься текущими делами и направляет все усилия на то, чтобы обеспечить успешное прохождение всех тестов.
принцип, называемый принципом единственной обязанности (SRP, Single Responsibility Principle). Он гласит, что при проектировании следует разделять аспекты системы, которые могут изменяться по разным причинам, и группировать вместе те аспекты, которые изменяются по одним и тем же причинам. Графические интерфейсы не являются исключением.
Задача решается таким проектированием системы, при котором графический интерфейс можно было бы рассматривать как API, а не как набор кнопок, ползунков, таблиц и меню.
Но настоящая причина, по которой эти тесты нельзя назвать избыточными, заключается в том, что тестирование не является их главной функцией. Тот факт, что они что-то проверяют, вторичен. Модульные и приемочные тесты прежде всего являются документами и лишь потом – тестами. Их главная цель – формальное документирование архитектуры, структуры и поведения системы.