Краткий ответ

Интеграционный тест должен проверить явно заданное поведение потребителя при неизвестном типе события: безопасное игнорирование, помещение в карантин или передачу в dead-letter queue. Главное — потребитель не должен аварийно завершаться, бесконечно повторять доставку или подтверждать сообщение так, чтобы оно безвозвратно исчезало вопреки принятой политике.

Исторический контекст

В событийных системах продюсер и потребитель часто разворачиваются независимо. Поэтому новый тип события может попасть к старому потребителю раньше, чем тот будет обновлён.

Так появилась необходимость проверять не только структуру известных событий, но и форвардную совместимость: способность старой версии корректно пережить расширение набора событий.

Постановка проблемы

Если потребитель считает любой неизвестный тип ошибкой программного кода, обновление продюсера может вызвать массовые повторы сообщений, переполнение очереди или остановку обработки известных событий.

Если потребитель безусловно подтверждает неизвестное сообщение, событие может потеряться навсегда. Поэтому контракт должен фиксировать не абстрактное требование «не падать», а конкретную стратегию завершения обработки и наблюдаемое последствие для сообщения.

Подробное решение

Интеграционный тест публикует событие с корректным конвертом, но с типом, которого нет в проверяемой версии потребителя. Затем он проверяет результат согласно принятой политике:

при игнорировании сообщение подтверждается, потребитель продолжает обрабатывать следующие события, а факт пропуска фиксируется в метрике или журнале;
при карантине сообщение перемещается в отдельное хранилище или очередь для анализа, после чего исходная доставка завершается без бесконечных повторов;
при временной невозможности определить обработчик сообщение не подтверждается сразу, но число повторов ограничивается политикой повторной доставки.

Проверять только отсутствие исключения недостаточно. Нужно подтвердить, что после неизвестного события известное событие из той же очереди всё ещё обрабатывается, а судьба неизвестного сообщения соответствует контракту.

Такой тест не должен требовать, чтобы старый потребитель умел выполнить бизнес-логику нового события. Его задача — проверить безопасное поведение на незнакомом типе. Компромисс очевиден: игнорирование повышает устойчивость, но может скрыть функционально важное событие; карантин сохраняет данные для расследования, но требует операционной поддержки и мониторинга.

Ситуация из практики

Продюсер добавил событие ЛимитКредитаИзменён, а старый потребитель знал только КредитОдобрен и ПлатёжПолучен. Вариант с аварийным завершением процесса был простым, но приводил к повторной доставке нового события и блокировал обработку последующих сообщений.

Вариант с безусловным подтверждением устранял блокировку, однако терял возможность расследовать неожиданное событие. Выбранное решение — отправлять неизвестные типы в карантин, подтверждать их исходную доставку, увеличивать метрику и продолжать обработку очереди.

Интеграционная проверка подтвердила три результата: старый потребитель не падает, неизвестное событие попадает в карантин, а следующее известное событие обрабатывается. Это позволило безопасно развернуть продюсер независимо от обновления потребителя.

Что кандидаты часто упускают

Достаточно ли проверить, что потребитель не завершился с ошибкой?

Нет. Процесс может продолжить работу, но бесконечно повторять одно сообщение, подтверждать его с потерей данных или блокировать очередь. Тест должен проверять состояние сообщения после обработки, число попыток, продолжение обработки следующих сообщений и наличие диагностического сигнала.

Можно ли считать неизвестный тип события обычной ошибкой схемы?

Не всегда. Ошибка схемы известного типа обычно означает повреждённое или несовместимое сообщение и может требовать отклонения. Неизвестный тип может быть штатным результатом независимого обновления продюсера, поэтому для него часто нужна отдельная политика форвардной совместимости.

Почему проверка только одного потребителя не гарантирует совместимость всей цепочки?

Потому что разные потребители могут иметь разные политики: один безопасно игнорирует незнакомые типы, другой падает, третий ошибочно подтверждает их. Контракт нужно проверять для каждого критичного потребителя, включая его взаимодействие с брокером, очередью повторов и карантином.