Автоматизированная проверка то проходит, то падает без изменений продукта. Какой механизм следует заподозрить в первую очередь?
В первую очередь следует заподозрить нестабильный, или flaky, тест: его результат зависит от времени, порядка выполнения, состояния среды или другой недетерминированной причины. Это не доказывает отсутствие дефекта в продукте, поэтому тест нужно отделить от основного набора и исследовать, сохранив при этом диагностическую информацию.
Проблема нестабильных тестов стала особенно заметной с распространением автоматизации, параллельного запуска проверок, распределённых систем и интеграций с внешними сервисами. Такие среды ускоряют обратную связь, но добавляют факторы, не полностью контролируемые тестом: задержки, порядок событий, общее состояние данных и различия окружений.
Подход к работе с flaky-тестами появился как ответ на снижение доверия к автоматизированному набору. Если команда регулярно перезапускает упавшие проверки до успешного результата, тесты перестают быть надёжным сигналом качества.
Одинаковый код и одинаковые входные данные не гарантируют одинаковый результат, если тест зависит от текущего времени, случайности, сетевого ответа, порядка выполнения или данных, оставшихся после другого теста. Иногда нестабильность вызвана самим продуктом, например гонкой, а иногда — ошибкой теста или инфраструктуры.
Опасно автоматически считать такой сбой ложным и просто перезапускать тест. Это может скрыть редкий дефект, а накопление нестабильных проверок приводит к игнорированию красных сборок и потере доверия к CI.
Нужно установить, что именно меняется между запусками. Проверяют логи, временные метки, идентификаторы данных, окружение, порядок тестов, сетевые ответы, параллельность и наличие общего состояния.
Типичные источники нестабильности:
Исправлять нужно причину, а не симптом. Например, вместо безусловной задержки используют ожидание наблюдаемого условия, для каждого теста создают изолированные данные, фиксируют генератор случайных значений или заменяют внешний сервис контролируемым заместителем.
Если причина пока не установлена, тест временно маркируют как нестабильный, собирают результаты нескольких запусков и назначают владельца расследования. Повторный запуск допустим как диагностический приём, но не как способ объявить сборку успешной.
Важное ограничение: нестабильность теста и редкий дефект продукта могут проявляться одинаково. Поэтому решение должно опираться на корреляцию с логами и состоянием системы, а не только на процент успешных перезапусков.
В CI проверка создания заказа иногда падала с ошибкой, что заказ не найден сразу после отправки запроса. Рассматривались три варианта: увеличить фиксированную задержку, повторять весь тест или исследовать синхронизацию между сервисами.
Увеличение задержки было простым, но замедляло набор и не гарантировало успех при большей нагрузке. Повтор всего теста маскировал проблему и мог создавать дубликаты заказов. Команда выбрала анализ временных меток и обнаружила, что проверка выполнялась раньше завершения асинхронной обработки.
Тест изменили так, чтобы он ожидал конкретное состояние заказа с ограниченным тайм-аутом, а тестовые данные сделали уникальными. В результате исчезли ложные падения, а превышение допустимого времени обработки стало фиксироваться как реальный дефект производительности.
Вопрос: Можно ли считать тест надёжным, если он успешен после повторного запуска?
Ответ: Нет. Успешный повторный запуск лишь показывает, что причина сбоя не проявилась снова. Он не объясняет, был ли первый результат вызван дефектом продукта, ошибкой теста или случайным состоянием среды. Повтор может использоваться для классификации и сбора статистики, но не должен заменять расследование.
Вопрос: Чем flaky-тест отличается от редкого дефекта продукта?
Ответ: Flaky-тест даёт разные результаты при сопоставимых условиях, даже если продукт не изменился. Редкий дефект продукта тоже может проявляться нерегулярно, но его причина находится в поведении системы: например, в гонке, тайм-ауте или некорректной обработке редкой последовательности событий. Различить случаи можно только по воспроизводимости условий, логам, трассировкам и контролю факторов среды; одного факта нестабильного падения недостаточно.
Вопрос: Почему изоляция тестов снижает нестабильность?
Ответ: Изолированный тест не зависит от данных, состояния и порядка выполнения других тестов. Если один тест создаёт или изменяет общие сущности, следующий может получить неожиданный результат даже без изменений в продукте. Уникальные данные, независимые фикстуры и корректная очистка уменьшают такие скрытые зависимости, но не устраняют нестабильность, вызванную временем, сетью или внутренними гонками системы.