Что такое продюсер и консюмер в брокерах сообщений
Что проверяют
Понимает ли тестировщик, где проходит граница ответственности в асинхронной интеграции и как её вообще проверять. Продюсер публикует сообщение и не знает, кто и когда его обработает, консюмер читает и обрабатывает. Отсюда главное следствие для QA: успешный ответ на стороне отправителя ничего не говорит о результате.
Как отвечать
Дайте роли и сразу добавьте, что модели брокеров разные. В очередях с доставкой по подписке брокер сам отправляет сообщение потребителю и убирает его после подтверждения, а необработанное уходит в отдельную очередь. В журнальных системах вроде Kafka потребитель сам читает по смещению, сообщение остаётся до конца срока хранения, и его можно прочитать повторно.
Дальше переведите на язык проверки: как убедиться, что продюсер отправил (подписаться отдельным тестовым потребителем или своей группой, чтобы не отбирать сообщения у рабочего сервиса), как проверить консюмер (подать сообщение руками, включая испорченное и повторное), что смотреть в наблюдаемости (отставание потребителя, очередь недоставленных, счётчик повторов).
Отдельно назовите контракт сообщения: схема, версия, обязательные поля. Совместимость проверяется отдельным тестом, потому что стороны выкатываются независимо.
Где спотыкаются
Проверяют только факт отправки. В логах отправителя всё хорошо, тест зелёный, а потребитель падает на разборе, и дефект приносит поддержка через неделю.
Переносят привычки очереди на журнал и наоборот: ждут, что прочитанное сообщение исчезнет, теряются, когда рабочий сервис забрал тестовое сообщение, читают под той же группой, что и стенд, и получают плавающие результаты.
Ждут ровно одной доставки. Типовая гарантия предполагает как минимум одну, дубли штатны при повторах и переподключениях, поэтому проверка идемпотентности обязательна. Рядом та же по природе ошибка: фиксированная пауза вместо ожидания по условию, из-за чего тест мигает и ему перестают верить.