Кратко и по делу — набор практик и конкретных приёмов для стабилизации flaky интеграционных тестов, вызванных временными зависимостями (таймеры, внешние API).
Изоляция
- Разделяйте уровни тестов: unit → component → integration → end‑to‑end. Flaky из‑за внешних зависимостей — держите на уровне интеграционных/е2е и минимизируйте их число.
- Запускайте интеграционные тесты в изолированной среде: отдельные namespace/контейнеры, ephemeral БД, testcontainers, docker compose с уникальными портами.
- Очистка состояния: настраивать/сбрасывать БД и очереди между тестами (fixture teardown или транзакция с rollback).
Заглушки / фикстуры / сервис‑виртуализация
- Подставляйте стабильные тест‑дублеры для внешних API: WireMock, MockServer, Mountebank, VCR/Betamax (record‑replay). Используйте контрактные стабы, генерируемые из контрактов.
- Для сложного поведения (латенси, ошибки) моделируйте детерминированно: задать фиксированную задержку/ошибку в стабе, не зависеть от непредсказуемых сетевых условий.
- Локальные «заглушки» для очередей/кэшей/хранилищ — in‑memory реализации при component‑тестах.
Повторяемость
- Фиксируйте начальное состояние: seed данных, фиксированные таймзоны, локали, конфиги.
- Избегайте использования реального времени в сгенерированных ID/токенах — используйте контролируемые значения или мок UUID.
- Не полагайтесь на порядок запуска тестов: тесты должны быть независимыми.
Контроль времени (mocking time)
- Внедрите абстракцию времени (Clock/TimeProvider) в код: в тестах подменяйте на FakeClock/ManualClock.
- Для событий/таймеров используйте виртуальный планировщик, который можно продвинуть вручную (например TestScheduler/VirtualTime для Rx/Reactor/akka).
- Для простых случаев — «заморозить» время (freezegun, Timecop) или установить системный Clock в тестовой среде.
- Делайте интервалы конфигурируемыми (снижение периодов в тестовой конфигурации), но тестируйте реальные интервалы в отдельном наборе интеграционных/нагрузочных тестов.
Контрактные тесты
- Потребитель‑ведущая контрактная разработка (Pact, Spring Cloud Contract): потребители публикуют контракты, провайдеры выполняют валидацию в CI.
- Поддерживайте два потока: провайдер‑верификация контрактов в CI и потребительские тесты, которые используют сгенерированные стабы. Это уменьшает зависимость от реального внешнего API.
- Включайте негативные сценарии и версии контрактов (backwards compatibility).
CI‑практики и управление флаки
- Разделяйте pipeline: быстрые unit/component тесты в PR; более дорогие интеграционные и контрактные тесты в отдельном stage (или execute in dedicated runners).
- Квота/карусель flaky‑тестов: выявляйте флаки (история результатов), помещайте их в quarantine и исправляйте первопричины; не скрывайте flakiness постоянными retry без анализа.
- Ограниченные retries для нестабильных сетевых запросов (с экспоненциальным backoff и jitter) — как временная мера, логировать и помечать.
- Собирать артефакты при падении (журналы, трассировки, снимки внешних стабов), чтобы ускорить расследование.
- Параллелизация и стабильность окружения: закреплённые runner‑ы с предсказуемыми ресурсами; избегать недостатка ресурсов, приводящего к таймаутам.
- Ночная/регресс‑прогоны: тяжелые интеграционные/е2e тесты запускать чаще чем в PR, но не блокировать разработку.
Дополнительные рекомендации и анти‑паттерны
- Инжектировать таймауты разумно: слишком маленькие таймауты — причина флаки; слишком большие — маскировка проблем. Логика таймаутов должна быть конфигурируемой.
- Логируйте и метрики: время ответа, частота retries, подконтрольность стаба/живого сервиса.
- Не использовать тестовый доступ к реальному третьему‑лицу в PR‑тестах; при необходимости — контракт/стаб/запись.
- Не прячьте flaky‑тесты под массовыми retry/skip без ревью — это снижает качество.
Короткий чеклист для внедрения
- Избежать прямых вызовов внешних API в PR‑тестах — заменить на стабы/контракты.
- Инжектировать Clock/TimeProvider, использовать FakeClock в тестах.
- Seed/очищать состояние БД и очередей, использовать ephemeral ресурсы.
- Настроить контрактное тестирование (Pact/SC Contract) в CI.
- Выделить flaky‑тесты, собрать логи и исправлять первопричины; временно quarantining + аналитика.
- Отдельный pipeline‑stage для тяжёлых интеграций, артефакты при падении.
Эти практики вместе дадут детерминированность тестов, уменьшат влияние внешних временных зависимостей и сохранят быстрый feedback для разработчиков.