Завтра отвечу по срп.

Да нечего отвечать,
Тестировщики пишут тесты, а разработчики используют TDD

А кодеры долбят одно и тоже без понимания причин и попыток понять или принять существование другой точки зрения :)

Принцип срп гласит что класс должен иметь только одну причину для изменения. Так вот с точки зрения актора сервис по доставанию популярных анекдотов за прошлый день соблюдает срп ибо как достаёт одно и то же для любого типа юзера. Он использует интерфейс Кеша для ускорения своей работы. Однако пхп не позволяет жестко регламентировать поведение реализации интерфейса в плане ошибок. Пхпдок это лишь подобие.
Поэтому на простой гет метод Кеша вызванный из сервиса необходимо как минимум 3 теста: удачные данные, неудачные данные, ошибка получения данных. И хорошо если ошибка эта это один тип ексепшена.
Учитывая требования моих проектов что сервисы не должны падать а адекватно обрабатывать баги и пытаться восстановиться то это проводит вот к такой вот наркомании по избыточному тестированию.

Приветствую. Вопрос к вашему разговору про тестирование и ТДД.  
Вот у меня есть форма, довольно большая, для создании сущности с связями О-М.  Приходят куча данных из для других сущностей (id) соответсвенно их нужно подтянуть из репо (чтобы проверить наличие в базе).  Одна команда/Хандлер в которую все эти данные скалдываются под одну транзакцию.
Выходит куча зависимотей в виде сервисов или репозиториев других сущностей у этого хандлера. Соответсвенно неимоверно неприятно и больно писать тесты, причем куча тестов в стиле ожидания вызовов этих зависимостей. Все это хрупко. Какой выход тут?

А какое тестирование вас интересует в данном случае ?

Да я даже не знаю как его назвать, ну если без записи в базу наверное это будет юнит. Но логики в основном нет. Приходят данные, соответственно надо проверить что они верно отформатировались для отдачи дальше по сервисам и что те сервисы их приняли.
Тут больше вопрос: раз тесты явно больно писать + куча зависимостей, значит неверный код/архитектура, разве нет?

Может отдавать такие данные в диспетчер событий, но отдавать всю команду + сущность в диспетчер это разве норм будет?

Больно писать потому что монотонно и одно и тоже ? Или потому что неудобно тестировать класс ?

Много зависимостей. Много зависимотей = боль.
Опять таки кейс: добавлям еще оду О-М связь. НАдо добавить в форму. Что у нас происходит? У нас падают все тесты, так как новая зависимость в конструкторе хандлера.

Да. Это будет нудно. Но вариантов тут нет. Если меняется конструктор то придётся поправить все тесты.
Вы можете применить вайтбокс тестирование и понаркоманить как я если у вас проекты уровня медицинских.
Можете использовать блекбокс если там только логика без зависимостей

Это по поводу юнитов только

Если проекты критичные я бы ещё добавил мутационные тесты.

А как считаете по поводу кейса с диспатчером? Т.е. хандлер заполняет только свою сущность, а дальше летит ивент с этой сущностью/или ее ID + целиковая команда?

Т.е. ивент PRE_FLUSH

А причём тут тесты ? Все равно вам нужно будет тестировать хендлер команды в котором может быть с 10ток зависимостей

Но это уже конечно запредельно :)

В хандлере не будет зависимотей, они уйдут полностью.

Только те нужны будут, которые для создания главной сущности.

Так вы просто перенесите обработку команды дальше. Но опять же зависит от логики. Позволено ли вам разорвать темпорал каплинг.