Автотест стоит денег дважды: когда его пишут и каждый раз, когда его чинят. Поэтому первый вопрос автоматизатора не «как», а «что и зачем».
Пирамида тестов
Классическая пирамида (Майк Кон) делит тесты по уровню:
- Unit внизу: проверяют функцию или класс в изоляции. Их много, они идут миллисекунды и падают точно в месте ошибки.
- Интеграционные и API посередине: проверяют связку компонентов, сервис с базой, контракт между сервисами. Медленнее, но всё ещё стабильны.
- E2E через UI наверху: проходят сценарий как пользователь. Дорогие, медленные, чаще всего флакают. Их мало, только ключевые пути.
Антипаттерн «рожок мороженого»: больше всего ручных и UI-тестов, мало юнитов. Регресс идёт часами, падения непонятно где искать.
Пирамида не догма. Для фронтенда популярен «трофей» (Кент Доддс): основной вес на интеграционных тестах компонентов. Для микросервисов важны контрактные тесты. На собесе ценят не заученную картинку, а умение объяснить, почему у вашего проекта такое распределение.
Что автоматизировать в первую очередь
Хорошие кандидаты:
- Смоук: логин, главный сценарий покупки или оплаты. Гоняется на каждый деплой.
- Регресс по стабильному функционалу, который часто прогоняют руками.
- Проверки с большим количеством данных: 50 комбинаций полей формы, граничные значения.
- То, что руками делать долго или нельзя: нагрузка, сотни API-вызовов, проверка после каждого коммита.
Плохие кандидаты: фича, которую переделывают каждую неделю, разовая проверка, визуальное «красиво ли», исследовательское тестирование.
ROI автоматизации
Грубая оценка: автотест окупается, когда (время ручного прогона × число прогонов) больше, чем (время написания + время поддержки). Если сценарий проверяют руками раз в квартал, а UI меняется каждый спринт, автотест уйдёт в минус.
Смоук, регресс, санити
- Смоук: быстрая проверка, что сборка вообще живая. Минуты.
- Санити: узкая проверка конкретной починки или фичи.
- Регресс: полный набор, чтобы убедиться, что старое не сломалось.
В CI это обычно разные наборы тестов, выбранные по меткам (@smoke, @regress) и запускаемые на разных событиях: смоук на каждый пул-реквест, полный регресс ночью.
Тестовые данные
Тест должен сам готовить свои данные и не зависеть от других тестов. Варианты: создать через API перед тестом, фабрики и билдеры, отдельная база с фикстурами, откат транзакции. Хардкод «пользователь id=42 в стейдже» ломается, как только его кто-то удалит.
Частые ошибки
- Автоматизировать всё подряд через UI, включая то, что проверяется одним API-запросом.
- Мерить успех процентом автоматизированных кейсов, а не временем регресса и найденными багами.
- Тесты, зависящие от порядка: второй тест использует заказ, созданный первым.
- Игнорировать флаки: команда перестаёт верить красному билду.
Что спросят на собесе
- Что такое пирамида тестирования и чем плох «рожок мороженого»?
- Какие кейсы вы бы автоматизировали первыми, а какие нет?
- Как посчитать, окупится ли автоматизация?
- Чем смоук отличается от регресса и как их разделить в CI?
- Как тесты получают свои данные?