Як у вас на проєкті тестують асинхронні мікросервіси?

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Як у вас на проєкті локально тестують мікросервіси, які спілкуються асинхронно через повідомлення в черзі?

Мені здається логічним зробити приблизно так.

Локально запускаємо сервіс в IDE. Сервіс налаштований на окрему тестову чергу (через змінні середовища чи якось інакше?). У вас це якийсь тестовий контейнер із чимось на кшталт Kafka чи LocalStack у Docker чи ця черга на окремому девелоперському середовищі у хмарі?

Потім вам знадобиться спеціальний скріпт для надсилання повідомлення в чергу. Він у вас, напевно, вже заготовлений у репозиторії, щоб будь-який член команди міг локально запускати end-to-end функціональність сервісу.

У вас так чи якось інакше?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

О каком уровне тестов мы говорим?
Навскидку:
1. Юнит тест — через мок передаём инициирующее сообщение, слушаем выходную очередь и забираем сообщение из неё.
2. Интеграционный тест: через мок передаём инициирующее сообщение, слушаем выходную очередь того микросервиса, что есть последним в списке.
3. E2E: передаём сообщение входящему сервису (скорее всего, через API?), смотрим результат работы приложения (возможно, тоже через API — но не факт).

testcontainers.com Тест підіймає все що треба, а далі вже звичаний флоу юніт теста

Підписатись на коментарі