Автоматизация тестов
Автоматизация — это не «записать клики и воспроизвести». Это инженерная дисциплина: вы пишете код, который проверяет другой код, и этот код тоже надо держать быстрым, стабильным и читаемым. Плохой автотест дороже ручной проверки — он падает то так, то эдак, требует правок при каждом рефакторинге UI и в итоге его отключают. Хороший автотест годами ловит регрессии молча.
Тема разложена от основания пирамиды (unit-тесты) к вершине (e2e) и дальше — к инфраструктуре, которая делает набор быстрым и повторяемым: моки и фикстуры для изоляции, Page Object и локаторы для UI-автоматизации, приёмы против flaky-тестов, метрики качества самих тестов (мутационное тестирование), нагрузочные виды и, наконец, CI/CD и Git как конвейер от коммита до прода. Главные ловушки названы в каждом слое. Полная карта — ниже.
Карта темы
- Unit-тест — наименьшая изолированная проверка одной функции с замоканными зависимостями и её место в основании пирамиды.
- E2E-тест — прогон всей системы через UI как реальный пользователь — максимум уверенности ценой скорости и хрупкости.
- Хороший автотест — принципы FIRST: независимость, детерминизм, читаемость и понятное сообщение об ошибке.
- Ассерты — проверки, роняющие тест, их виды и различие soft против hard.
- Setup-хуки JUnit — разница между подготовкой перед каждым тестом и один раз на класс.
- Мокирование — подмена реальной зависимости управляемым дублёром ради изоляции и детерминизма.
- Локаторы — способы найти элемент (id, CSS, XPath) и компромисс стабильность против гибкости.
- Паттерн Page Object — страница как класс с методами, централизующий локаторы и убирающий дублирование.
- Appium против нативных инструментов — кросс-платформенная одна база против быстрых нативных Espresso и XCUITest.
- Flaky-тесты — недетерминированные тесты, их причины и лечение через явные ожидания и изоляцию.
- Антипаттерны автоматизации — sleep-ожидания, взаимозависимые тесты и пирамида-рожок.
- Мутационное тестирование — намеренные дефекты в коде, измеряющие качество самих тестов.
- Линтер — статический анализатор, ловящий стиль и класс ошибок до запуска кода.
- Параллельный и распределённый прогон — как ускорить набор и чем шардирование отличается от конкурентности.
- Нагрузочное тестирование — поведение системы под ожидаемой и пиковой нагрузкой и её инструменты.
- Нагрузка, стресс и синтетический мониторинг — три вида проверки производительности с разными целями.
- CI/CD — автоматические сборка, тесты и доставка каждого изменения от коммита до прода.
- Git и Git Flow — базовые команды Git и модель ветвления для структурированного пути к релизу.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
Заменять явное ожидание на Thread.sleep | Гонки по времени, flaky-тесты и медленный набор |
| Держать flaky-тест в наборе вместо карантина | Падает доверие ко всему прогону, реальные баги тонут в шуме |
| Строить пирамиду-рожок (много UI-тестов) | Медленный, хрупкий и дорогой в поддержке набор |
| Класть сырые локаторы прямо в тесты | Правка UI ломает десятки тестов вместо одного класса страницы |
Хвататься за XPath, где хватит id или CSS | Хрупкие и медленные селекторы |
| Делить изменяемое состояние в hook на класс | Тесты зависят друг от друга — ломается изоляция |
| Считать выживший мутант признаком хороших тестов | Наоборот — он обнажает пробел в проверках |
| Путать нагрузочное и стресс-тестирование | Неверные цели и метрики, пропущенные узкие места |
| Полагаться на покрытие строк как на меру качества | Строка выполнена не значит, что баг в ней пойман |
Значение для собеседований
Автоматизацию спрашивают не ради синтаксиса конкретного фреймворка, а чтобы проверить инженерную интуицию. Кандидат, который объясняет, почему пирамида имеет такую форму, чем мок отличается от реальной зависимости и почему flaky-тест иногда хуже его отсутствия, сразу опережает того, кто умеет только записать сценарий в рекордере.
Что обычно проверяют:
- Пирамиду тестов: почему unit-тестов много, e2e — мало, и что такое антипаттерн-рожок.
- Как устроен хороший автотест — независимость, детерминизм, изоляция через моки и фикстуры.
- UI-автоматизацию: локаторы, их стабильность и паттерн Page Object.
- Работу с flaky-тестами, различие нагрузочного и стресс-тестирования, роль CI/CD.
Типичный неверный ответ: «чем больше UI-тестов, тем надёжнее» или «flaky-тест просто надо перезапускать». На деле тяжёлый UI-слой делает набор медленным и хрупким, а перезапуск flaky-теста маскирует причину и подрывает доверие ко всему прогону — такой тест надо стабилизировать или удалить.