Пирамида тестов на практике: где E2E убивают скорость

AnnaMiller

New member
Когда-то я искренне верил, что сквозные тесты — это высшая форма инженерной зрелости. Ну серьёзно: если автотест умеет открыть браузер, залогиниться, оформить заказ и проверить письмо в почтовике — это же почти как живой пользователь, только без кофе и перекуров. Мы гордились этим пайплайном, вешали бейджи в репозитории и рассказывали на планёрках, что у нас покрытие бизнес-процессов почти сто процентов. А потом я впервые замерял, сколько времени команда тратит на ожидание. Спойлер: результат был неприличным.

Наш проект был классической средней SaaS-платформой: фронт на реакте, бэк на нескольких сервисах, база, очередь, внешние интеграции с платежами и доставкой. Сначала сквозных сценариев было штук двадцать, и они бегали минуты за четыре. Через год их стало почти триста — потому что каждый новый баг мы закрывали не юнит-тестом, а ещё одним сценарием «чтобы точно не повторилось». Прогон разросся до часа с лишним, а в чёрную пятницу мы как-то ждали зелёного билда два с половиной часа. Люди в это время не работали. Они пили кофе и обновляли страницу со сборкой.

Самое обидное началось не с длительности, а с хрупкости. Половина падений была не про реальные дефекты, а про анимацию, которая не успела доехать, про куку, которая прилипла не в ту сессию, или про двадцать миллисекунд разницы в таймауте на слабой машине раннера. Инженеры завели привычку перезапускать упавшие сценарии, и незаметно у команды появилась культура «красный — это, наверное, флак, забей». Как только тесты перестают быть источником правды, они перестают быть тестами. Это, пожалуй, главный урок, который я вынес за те годы.

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

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

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

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

А теперь вопрос к вам, коллеги с форума: расскажите, где в вашей практике сквозные тесты действительно спасли релиз, а где оказались просто дорогой привычкой? И если у вас есть свой приём, который вернул CI скорость, — поделитесь, я всё ещё коллекционирую хорошие идеи.
 
Назад
Вверх