Как расположить виды тестирования по количеству в порядке убывания

Что проверяют

Знаете ли вы пирамиду тестирования и можете ли объяснить, почему она такой формы. Следом обычно спрашивают, как это выглядит в вашем Python-проекте и какими инструментами покрыт каждый уровень.

Как отвечать

По количеству, от большего к меньшему:

• модульные (unit): их больше всего. Проверяют функцию или класс в изоляции, выполняются за миллисекунды. В Python это pytest, подмены через unittest.mock или pytest-mock, наборы входных данных через @pytest.mark.parametrize;
• интеграционные: заметно меньше. Код работает с настоящей базой, очередью, кэшем. Поднимают их через Docker или testcontainers, эндпоинты веб-сервиса проверяют через TestClient в FastAPI или тестовый клиент Django;
• сквозные (E2E, UI): единицы или десятки. Проходят пользовательский сценарий через всю систему, например на Playwright. Медленные, хрупкие, дорогие в поддержке;
• ручные и исследовательские: вершина, то, что сложно или бессмысленно автоматизировать.

Главное объяснить причину: чем выше уровень, тем медленнее прогон, дороже поддержка, чаще случайные падения и сложнее понять, где сломалось. Упавший unit-тест указывает на функцию, упавший E2E на «что-то во всей системе». Иногда называют пропорцию 70/20/10, но это ориентир, а не стандарт.

Уточните, что регрессионное, смоук и приёмочное тестирование в пирамиду не укладываются: это не уровни, а цели прогона. Регрессия прогоняет тесты всех уровней после изменений.

Можно упомянуть альтернативы: «кубок» (testing trophy) с упором на интеграционные тесты популярен во фронтенде, а перевёрнутая пирамида («рожок мороженого») считается антипаттерном.

Где спотыкаются

Ставят в один ряд уровни и типы: «unit, интеграционное, регрессионное, нагрузочное». Это разные оси, и интервьюер это заметит.

Сортируют по важности, а не по количеству. Сквозные тесты важны, но их должно быть мало.

Хвастаются сотнями unit-тестов, где замокано всё. Такие тесты проверяют моки, а не поведение, и ломаются при любом рефакторинге.