Почему выбрали Kafka

Что проверяют

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

Как отвечать

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

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

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

Где спотыкаются

Ставят паузу вместо ожидания события. Тест зелёный на быстрой машине и красный в общей очереди сборок, а лечат это увеличением паузы, пока прогон не растянется на час.

Читают той же группой потребителей, что и приложение. Тест забирает сообщение у сервиса, сервис ничего не обрабатывает, и дефект спокойно уезжает в продукт мимо проверки.

Заводят баг на нарушенный порядок. Глобального порядка в топике нет и не было: связанные события должны идти с одним ключом, и корректный дефект формулируется про ключ партиционирования, а не про очерёдность.