можно (https://dzone.com/articles/rabbitmq-request-response)

но зачем?

Логику с ветвлениями - в классы где поменьше зависимостей, а если это контроллер в котором просто цепочка вызовов, то 1 интеграционный/приёмочный тест на него и норм

Асинхрон полный... Да и хотелось бы как то агрегирраать результаты с нескольких сервивов но не знаю подойдёт ли для этого messenger...?

GOOS не понравилос тем, что там пример чисто про полный e2e и в конце чет порассуждали о дизайне кода и тестов, ну вот прям как-то слабо совсем

покажи что ты тестишь

Introdution to EventStorming не закончена, и чет походу наврядли будет когда-нибудь

Как мне уведомить первый сервис о том что второй закончил делать что то для того что бы по ws сообщить на ui что закончилась обработка и можешь идти в свой кабинет забирать свой обработанный документ?

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

1. выносишь всю логику из контроллера в зависимости. Эти зависимости - у них должно быть мало зависимостей - и тестишь юнитами.
2. контроллер закрывается одним позитивным приемочным тестом

а мне недописанность этой книги чем-то даже нравится

операции чтения нет смысла делать через очереди. Ну то есть - сходить по http или там grpc и сагрегировать данные проще банально. Это и быстрее и надежнее и проще... ну а если какой-то сервис "упал" - очереди тебя тут не спасут. В том плане что проще сделать ретраи.

Есть пожалуй оч узкая категория кейсов когда тебе агрегация нужна для интеграций каких. там в целом "можно было бы и через очереди потому что нет ограничений на время обработки". А для UI если не вышло за 100ms забрать все данные по причие падения сервиса - ну покажешь там блок мол "шот пошло не так" у кусочка данных

с помощью события и шины.

Этот вопрос не связан в обсуждаемым выше

оставь очереди и шины и вот это все для записи и изменений стэйта. на чтение лучше "синхронно" делать

запомни одно простое правило - если тесты писать неудобно - значит ты чет не то тестишь или тестируемый код кривой. Код вида

public function doStuff(int $id)
{
    $data = $this->oneDependency->hahaha($id);
    $anotherResult = $this->twoDependencies->ahahah($data);
    return $this->threeDependencies->ahahah($anotherResult)
}

такое нет смысла покрывать юнитами. Это тупая координация действий и простой приемочный тест с этим справится лучше.

Необходимость покрывать юнитами тестами тут может возникнуть когда у тебя часть логики вытекает в этот "контроллер" (GRASP controller паттерн). Мол он и координирует действия и трансформирует данные например как-то или выбирает кто следующий должен на основе предыдущего результата. Тут конечно лучше попытаться добавить еще зависимость которая эту логику от нас спрячет.

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

- много логики - избавляемся от зависимостей настолько насколько это возможно.
- много зависимостей - избавляемся от логики настолько насколько это возможно.

всем спасибо за советы, в целом, если усреднить опыт, какую часть времени занимают тесты (не при TDD) подходе, и после какого порога бить тревогу? Скажем если я трачу на тесты времени в 3 больше чем на фичу, и так происходит чаще всего, с этим стоит что-то решать?

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

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

Так же попробуй именно TDD. У тебя сейчас вопрос "а как это тестить" возникает после реализации и приходится думать о том что ты сделал дважды. Только имей ввиду что любое изменение воркфлоу не даст тебе профита сразу, будет период когда будет казаться что это дольше

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

если много зависимостей и много логики - надо рефачить. это обычное дело тоже, когда так

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

у вас там требование со 100%-м покрытием юнитами?