Например, если ваше приложение содержит только базовые операции создания, чтения, обновления и удаления (CRUD) с минимумом бизнес-правил, ваша пирамида тестирования будет больше напоминать прямоугольник с равным количеством юнит- и интеграционных тестов, без сквозных тестов. Юнит-тесты менее полезны в ситуациях, в которых отсутствует алгоритмическая или бизнес-сложность, — они быстро вырождаются в тривиальные тесты. В то же время интеграционные тесты полезны даже в таких случаях; каким бы простым код ни был, важно проверить, как он работает в интеграции с другими подсистемами (например, базой данных). В результате в CRUD-приложениях у вас будет меньше юнит-тестов и больше интеграционных. В самых тривиальных случаях интеграционных тестов может быть даже больше, чем юнит-тестов.
Другое исключение из пирамиды тестирования — API, обращающиеся к единственной внепроцессной зависимости (например, базе данных). В таких приложениях логично задействовать больше сквозных тестов. Так как пользовательский интерфейс отсутствует, сквозные тесты будут выполняться достаточно быстро. Затраты на сопровождение тоже будут не особенно велики, потому что вы работаете только с одной внешней зависимостью — базой данных. В такой среде сквозные тесты по сути неотличимы от интеграционных. Отличается только точка входа: сквозные тесты требуют, чтобы приложение было где-то размещено для полной эмуляции конечного пользователя, тогда как интеграционные тесты обычно запускают приложение в том же процессе. Мы вернемся к пирамиде тестирования в главе 8, когда речь пойдет об интеграционном тестировании.
Из Принципы юнит-тестирования.
От себя: наверное к концу книги автор придет к тому, что наконец-то! расскажет про Testing trophy.