Что такое пирамида тестирования?

Давай разберём эту пирамиду тестирования, а то некоторые думают, что автоматизация — это просто накидать тысячу скриптов на селениум и страдать. Это пиздец, а не стратегия.

Представь себе реальную пирамиду, только вместо камней — тесты. Основание, где всё держится — это юнит-тесты. Их должно быть овердохуища. Они быстрые, дешёвые и летают как угорелые. Их задача — проверить каждую мелкую функцию, каждый метод, чтобы разработчик, когда что-то сломал, узнал об этом через три секунды, а не через три часа. Если их мало — вся пирамида хуй стоит, развалится при первом же чихе.

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

А на самой верхушке, где её едва видно, сидят UI или E2E-тесты. Их должно быть совсем немного, только для самых критичных сценариев. Потому что это, ёпта, самые медленные, самые хрупкие и дорогие в поддержке ублюдки. Каждый раз, когда дизайнер передвинет кнопку на пиксель, такой тест может сломаться, и ты будешь тратить полдня, чтобы понять, это баг или просто верстку поправили. Доверия к ним — ноль ебать, они постоянно подводят.

Как это в жизни выглядит? Вот смотри, на проекте я делаю так:

• Юнит-тесты (на pytest, например) — ими покрываю всю бизнес-логику на бэкенде. Чтобы любое изменение в расчётах сразу вылезало.
• API-тесты (типа на requests или REST Assured) — проверяю, что сервисы между собой правильно ручкуются, контракты не побились.
• E2E-сценарии (Selenium/Playwright) — оставляю буквально штук 10-15 на самые главные пути пользователя: зарегистрироваться, купить товар, оформить заказ. Всё. Больше — самоубийство.

Если нарисовать эту хитрую жопу, то выйдет примерно так:

Количество тестов
    ^
    |           /
    |          /     E2E (UI) Tests
    |         /____  Integration/API Tests
    |        /________  Unit Tests
    +----------------------> Скорость выполнения / Стоимость поддержки

Смысл в чём? Чем ниже уровень, тем тестов больше, они быстрее и надёжнее. Чем выше — тем их меньше, они медленнее и капризнее. Если делать наоборот и нагороду кучу жирных UI-тестов — получится перевёрнутая пирамида, которая накроется медным тазом при первой же попытке что-то изменить. Всё будет падать, работать часами, а команда будет только и делать, что чинить эту хрупкую хуйню вместо разработки.

Короче, запомни: прочный фундамент из юнитов, разумный слой интеграционных проверок и лишь тонкая декоративная маковка из E2E. Тогда и жить будет проще, и терпения на поддержку хватит.