Практическая ситуация: HTTP-команда запускает асинхронную обработку, а результат становится доступен позже. Как построить интеграционную проверку, чтобы она не зависела от фиксированной задержки?
Проверку следует строить как ограниченное ожидание по условию: после отправки команды тест периодически проверяет наблюдаемое состояние результата до выполнения ожидаемого условия или истечения общего тайм-аута. Фиксированная пауза ненадёжна: слишком короткая задержка даёт ложные падения, слишком длинная замедляет тест.
Асинхронные интеграции появились как способ развязать время обработки запроса и время готовности результата. Очереди, фоновые работники и событийные взаимодействия повышают устойчивость и пропускную способность системы, но создают eventual consistency: сразу после команды связанные данные могут быть ещё не видны.
Обычная проверка «отправить запрос, подождать несколько секунд, проверить результат» плохо соответствует такой модели. Поэтому в интеграционных тестах применяют проверку готовности по наблюдаемому условию с конечным пределом ожидания.
После HTTP-команды система может сначала принять задачу, затем поставить её в очередь, обработать и только после этого записать или опубликовать результат. Время каждого этапа зависит от нагрузки, планирования, сетевых задержек и состояния зависимостей.
Если тест проверяет результат немедленно, он путает корректную задержку обработки с дефектом. Если тест всегда ждёт фиксированный интервал, он остаётся либо flaky, либо неоправданно медленным и всё равно может не выдержать редкий более долгий сценарий.
Тест должен выполнять следующие действия:
Важно отделять тайм-аут одной проверки от общего тайм-аута ожидания. Запрос к системе может временно завершиться сетевой ошибкой или ответом о ещё неготовом ресурсе; такие состояния нужно обрабатывать по правилам тестируемого контракта, а не безусловно считать успехом или немедленным дефектом.
Проверяемое условие должно быть достаточно строгим. Одного факта существования записи может быть мало: тесту может требоваться конкретный статус, версия, идентификатор операции или полный набор обязательных полей. При этом не следует проверять внутренние промежуточные состояния, если они не входят в внешний контракт.
Общий тайм-аут должен отражать допустимую SLA задержку и особенности тестовой среды. Слишком большой тайм-аут маскирует зависшие процессы, а слишком маленький создаёт нестабильность. Интервал опроса выбирают так, чтобы не перегружать систему и не увеличивать заметно время теста.
Для диагностики при падении полезно сохранять идентификатор операции, число попыток, последнее состояние результата, ответы зависимостей и причину завершения. Нельзя превращать такой механизм в бесконечное ожидание: отсутствие результата в пределах согласованного срока является значимым результатом теста.
Сервис принимает запрос на формирование отчёта и возвращает идентификатор задания. Отчёт создаётся фоновым обработчиком, поэтому сразу после отправки запроса ресурс отчёта может отсутствовать.
Рассматривались три варианта. Немедленная проверка была простой, но давала ложные падения. Фиксированная пауза в десять секунд снижала число падений, однако замедляла успешные прогоны и иногда не выдерживала нагрузочные пики. Проверка внутренней таблицы обработчика была бы быстрой, но делала тест зависимым от реализации и не проверяла внешний интеграционный контракт.
Выбрали опрос внешнего статуса отчёта по уникальному идентификатору с интервалом и общим тайм-аутом. Тест завершался сразу после появления статуса готовности, а при тайм-ауте сохранял последний ответ сервиса. В результате тест проверял фактическую доступность результата, не зависел от произвольной паузы и позволял отличить медленную обработку от отсутствия результата.
1. Как отличить корректное ожидание от скрытия зависшего процесса?
Ожидание должно иметь конечный общий тайм-аут, связанный с ожидаемым контрактом или SLA. После его истечения тест обязан завершаться ошибкой с диагностикой, а не продолжать попытки. Полезно также различать состояния «обработка продолжается», «обработка завершилась ошибкой» и «результат не найден»: они указывают на разные дефекты.
2. Что делать, если повторная проверка результата сама изменяет состояние системы?
Для ожидания нужно выбирать безопасную операцию чтения. Если получение результата имеет побочный эффект, следует использовать специально предусмотренный статусный ресурс или другой идемпотентный способ наблюдения. Иначе сам тест может влиять на систему и искажать результат проверки.
3. Почему уникальный идентификатор операции важен даже в изолированной тестовой среде?
Без него тест может случайно увидеть результат другой операции с теми же бизнес-параметрами. Уникальный идентификатор связывает отправленную команду с конкретным результатом, предотвращает ложноположительные проверки и упрощает диагностику параллельных прогонов. Одной очистки старых данных недостаточно, если система допускает задержавшиеся сообщения или повторную обработку.