клиент кафки и писать/читать после/перед тестами

спасибо) для начала уже не плохо )

ну если сервис зависит только от кафки то это изи должно быть

Да, только если планируешь паралелить то возможно там с прослушкой месседжей хитро будет

ну по факту да только кафка и таблица в постгресе, просто я с этим еще не сталкивался и для меня это как рокет саинтс

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

Готов покрыть время кто поможет и объяснит

Вопрос такой. Какие подходы вы используете при тестирование бэкенд api сервисов?
Мы сначала использовали подход тестирования с живыми зависимостями (базой).
Затем перешли на тесты с моками результатов от БД.
Но оба эти подхода имеют как плюсы так и минусы.
1.Тестироване без мока БД.
   минусы:
    - нужно делать пре и пост манипуляции с данными (добавлять, потом обязательно чистить )
    - тратит больше ресурсов
    - нужно более сложное окружение для теста (поднятая база)
    - нужна желательно отдельная базы
    - желательны пресеты и фикстуры данных

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

2.Тестироване на мока данных из БД.  
   минусы:
   - сами моки, это капец не тревиальная задача,
   иногда код для подготовки мока занимает 30+ строк, да и назвать его простым тоже нельзя
   - сильно падает смысл проверки формата результата работы сервиса, т.к. структура мока напрямую влияет на выходной результат
   (например тест на проверку не улетает ли на ружу хэш пароли, при получение инфа о пользователе)
   - тестирование НЕ максимально приближено к реальному поведению
   
   плюсы:
   - тесты отрабатывают быстрее
   - никаких зависимостей
   - простая среда исполнения

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

ну да это первый наш подход

мы правда не юзали отдельную базу и пресеты ))

Не так уж это и долго. И пост операции не нужны - прибил базу и всё

а это ваш реальный опыт или размышления

Реальный. Я их не пишу, но пользуюсь (тесты для симфони на phpunit)

не всегда это помогает, например когда уникальные юзеры например

Зависит от проекта. Но моки - это реально геморрой ). Да и они на самом деле нужны только для внешки по отношению к тестируемому объекту

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

потому что  посути, правильный выходной json невсегда гарант что все норм отработало

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

В итоге пишете второй бэкенд)