Testing Trophy, или Кубок Тестирования

Мы выяснили, что есть три уровня тестов — сквозные, интеграционные и модульные. Какой из уровней следует развивать в первую очередь, а какой — в последнюю?

Соотношение уровней в пирамиде тестирования

Пирамиду автоматизации тестирования часто воспринимают как соотношение количества тестов:

В разных источниках встречаются фразы вида:

Наибольший объём тестов должен быть на нижних уровнях

Иногда указывают более конкретные соотношения:

Модульные тесты должны составлять 80%, интеграционные и сквозные тесты — оставшиеся 20%

Это ошибочное предположение, которого не было в первоисточнике термина «Пирамида автоматизации тестирования»: The Forgotten Layer of the Test Automation Pyramid.

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

Testing Trophy

Для многих прикладных задач можно отдать приоритет интеграционным тестам, используя их как приёмочные. Эту идею подчёркивает концепция Testing Trophy, которую ввёл в 2018 году Kent C. Dodds, автор React Testing Library:

В кубок тестирования заложены две идеи:

1. Интеграционные тесты часто дают наилучшее сочетание стоимости и полезности, что делает их лучшим способом получить уверенность в собственном коде
2. Множество простых проблем в коде хорошо находят статические анализаторы кода, что позволяет не ловить опечатки модульными тестами

При этом кубок тестирования не исключает других уровней тестов:

Какую фигуру тестирования выбрать?

Всё зависит от проекта. Есть соображения, основанные на личном опыте:

1. Для Web-приложений хорошо работает Testing Trophy — при этом все уровни, кроме сквозных тестов, реализуются раздельно для фронтенда и бэкенда
2. Для библиотек и фреймворков лучше сделать упор на модульные тесты, но следует уделить внимание и интеграционным тестам, тестирующим реалистичный пример использования библиотеки
3. Для некоторых платформ — например, Desktop или Mobile приложений — разработка интеграционных тестов может быть осложнена ограничениями платформы. В этом случае можно сделать упор на сочетание модульных и сквозных тестов, и продолжать искать возможности удобного написания интеграционных тестов.

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