1. Flaky-тесты
Что это такое:
Flaky-тесты — это автоматические тесты, которые иногда проходят, а иногда падают без изменений в коде. То есть, они ведут себя нестабильно, и это делает их ненадёжными.
История и происхождение термина:
Термин "flaky test" стал популярным в начале 2010-х годов, особенно в среде разработчиков, использующих CI/CD (например, Jenkins, Travis CI). Одним из первых, кто начал активно обсуждать flaky-тесты, была команда Google. В 2016 году они даже опубликовали исследование о том, как они борются с flaky-тестами.
Коротко суть той статьи на русском:
📌 Суть статьи:
Google ежедневно запускает огромное количество автоматических тестов, чтобы проверять изменения в коде. Однако примерно 1,5% всех запусков тестов дают "flaky" (нестабильные) результаты — то есть один и тот же тест может как пройти, так и провалиться при одинаковом коде.
Это создает множество проблем:
84% всех переходов от "прошёл" к "провалился" — это flaky-тесты, а не реальные ошибки.
Это замедляет разработку, так как приходится тратить время на выяснение: ошибка настоящая или тест "флейковый".
Разработчики могут игнорировать настоящие ошибки, думая, что это просто флейк.
Каждый проект содержит ~1000 тестов, и даже 1,5% флейков — это 15 тестов, которые могут ложно провалиться и задержать релиз.
🛠 Как Google борется с flaky-тестами:
1. Повторный запуск только упавших тестов — чтобы проверить, действительно ли они нестабильны.
2. Автоматическая повторная проверка — если тест упал, его запускают ещё раз.
3. Маркировка теста как flaky — он считается проваленным только если упал 3 раза подряд.
4. Инструмент карантина — если тест слишком нестабилен, его временно исключают из обязательных проверок и создают баг для исправления.
5. Отслеживание изменений флейковости — чтобы понять, что вызвало ухудшение стабильности теста.
6. Выделенная команда — занимается анализом и предоставлением информации о flaky-тестах разработчикам.
Причины появления flaky-тестов:
- Зависимость от времени (например, sleep в тестах)
- Сетевые вызовы и нестабильные API
- Параллельное выполнение тестов
- Неправильная инициализация данных
- Зависимость от внешней среды (например, файловая система, БД)
Нюансы:
- Flaky-тесты подрывают доверие к автоматизации.
- Их сложно отлаживать, потому что они не всегда воспроизводятся.
- Часто их временно "игнорируют", что может скрыть реальные баги.
2. Shift-left testing
Что это такое:
Shift-left testing — это подход, при котором тестирование начинается на более ранних этапах разработки, а не только после написания кода. Идея — "сдвинуть тестирование влево" по временной шкале разработки.
История и происхождение:
Термин "shift-left" появился в начале 2000-х годов в контексте Agile и DevOps. Одним из первых, кто популяризировал этот подход, был Larry Smith в своей статье "Shift-Left Testing" (2001). Позже концепция получила широкое распространение благодаря DevOps-движению.
Почему это важно:
- Чем раньше найден баг, тем дешевле его исправить.
- Повышается качество продукта.
- Снижается время выхода на рынок (time-to-market).
Примеры shift-left практик:
- Написание unit-тестов до реализации (TDD)
- Интеграция QA в команды разработки
- Использование статического анализа кода
- Раннее моделирование требований и тест-кейсов
Нюансы:
- Требует изменения культуры в команде.
- QA должны обладать техническими навыками.
- Не отменяет тестирования на более поздних этапах — это дополнение, а не замена.
3. Пирамида тестирования (Test Automation Pyramid)
Что это такое:
Пирамида тестирования — это концепция, описывающая оптимальное распределение автоматических тестов по уровням:
- Unit-тесты (основание) — быстрые, дешёвые, много.
- Интеграционные тесты — средний уровень.
- UI/End-to-End тесты (верхушка) — медленные, дорогие, мало.
История и происхождение:
Концепцию предложил Mike Cohn в своей книге *"Succeeding with Agile"* (2009). Он использовал метафору пирамиды, чтобы показать, что основная масса тестов должна быть на уровне юнитов.
Зачем нужна пирамида:
- Обеспечивает баланс между скоростью и надёжностью.
- Помогает избежать "антипаттерна мороженого" (объяснение ниже, когда почти всё тестирование — через UI).
- Снижает стоимость поддержки тестов.
Нюансы:
- Не универсальна: для микросервисов или ML-систем может быть другая структура.
- Требует хорошей архитектуры кода (иначе unit-тесты сложно писать).
- Иногда дополняется "обратной пирамидой" (объяснение ниже) для legacy-систем.
🍦 Антипаттерн "мороженое" (Ice Cream Cone Anti-Pattern)
Что это такое:
Это антипаттерн (то есть плохая практика) в автоматизации тестирования, при котором основной упор делается на UI-тесты, а юнит- и интеграционные тесты либо отсутствуют, либо их очень мало.
Выглядит это примерно так:
🍦 UI-тесты (много, медленно, нестабильно)
🧁 Интеграционные тесты (немного)
🍪 Юнит-тесты (почти нет)
Почему это плохо:
- UI-тесты медленные и хрупкие — они часто ломаются при малейших изменениях интерфейса.
- Их дорого поддерживать.
- Они не покрывают всю бизнес-логику, особенно если логика спрятана в бэкенде.
- Отсутствие юнит-тестов делает отладку сложной: если UI-тест упал, непонятно, где именно ошибка.
Откуда название:
Визуально структура напоминает рожок мороженого — широкая "шапка" из UI-тестов и узкое основание из юнитов.
🔄 Обратная пирамида (Upside-down Pyramid)
Что это такое:
Это ещё один антипаттерн, похожий на "мороженое" (практически то же самое), но с акцентом на неправильное распределение тестов в целом. В такой "пирамиде" больше всего тестов на верхнем уровне (UI), меньше — на среднем (интеграции), и почти нет на нижнем (юниты).
🔺 UI-тесты (много)
🔸 Интеграционные тесты (мало)
🔹 Юнит-тесты (единицы)
Почему это плохо:
- Нарушается принцип "тестировать как можно ближе к коду".
- Сложно локализовать ошибки.
- Тесты становятся медленными и ненадёжными.
- CI/CD процессы тормозятся из-за долгого прогона тестов.
Когда такое встречается:
- В legacy-проектах, где сложно писать юнит-тесты.
- В проектах без культуры TDD/BDD.
- Когда автоматизация начинается "снаружи", без понимания архитектуры приложения.
💡 Как должно быть:
Пирамида тестирования Майка Кона:
🔺 UI (мало)
🔸 Интеграционные (средне)
🔹 Юнит (много)
Такой подход:
- Быстрее
- Надёжнее
- Дешевле в поддержке
- Даёт быструю обратную связь при ошибках
Вместо заключения:
Автоматизация тестирования — это не только про инструменты, но и про мышление. Понимание таких концепций, как flaky-тесты, shift-left и пирамида тестирования, помогает строить надёжные процессы, экономить ресурсы и выпускать качественный продукт. Не бойся пересматривать подходы — иногда, чтобы двигаться вперёд, нужно сначала сдвинуться влево. 😉
Спасибо, что прочли до конца 🙌
Подписывайтесь на мой канал в Телеграм или в VK — впереди ещё много интересного про ИИ, NLP и тестирование!
До встречи в следующих статьях! 💡