Дмитрий Гординский

Проще переписать чем тестировать такой метод со статическими вызовами.
Сделайте фабрику без статического вызова и заинжекте её через конструктор этого хэндлера.

В методе request третьей строкой создаётся экземпляр объекта Request, и далее именно он передается в метод ClientInterface::sendRequest. А вы в тесте ожидаете что туда будет передан мок:

->with($this->createMock(\Nyholm\Psr7\Request::class))

Сохраняйте мок в свойствах своего теста, и уже их инжекте, и через них же манипулируйте моком.

Код из примера помимо вызова статического метода ещё и преобразует его результат. Так что тестировать есть смысл.

Если в кейсе из примера EntityManager передается как зависимость в конструктор:

- Создать мок для StopEmailRepository в котором и описать что метод findOneBy должен быть вызван один раз, с таким то значением.
- Создать мок для EntityManager в котором описать что метод getRepository должен возвращать мок из предыдущего пункта.
- Создать екземпляр тестируемого объекта в конструкто которого и передать мок EntityManager

1) Если всё поля в DTO обязательные - лучше требовать передавать их в конструкторе, и делать DTO имутабельной.
2) Если необходимо поэтапно сетить разные фрагменты DTO - можно использовать для этого паттерн Builder
3) Dataprovider в PHPUnit может быть генератором, и возвращать кейсы через yield. Таким образом мы можем в процессе заполнения одного объекта поэтапно тестировать его валидность.
4) Для каждой DTO можно писать отдельный тест, а вместо обязательных дочерок создавать моки.

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

Так как в тегах указано именно модульное тестирование - упомяну в первую очередь о нем.
Почти наверняка и роутинг и авторизация реализована не самостоятельно, а посредством подключения сторонних библиотек, по хорошему они уже и без вашего участия покрыты модульными тестами, и делать это снова нет необходимости. А вот что стоит оттестировать в первую очередь так это интеграцию этих библиотек в приложения. Что как бы намекает об интеграционных тестах, которые я бы и посоветовал применить.

Протестировать что роуты требующие авторизации не работают без неё, что структура ответа соответствует ожидаемой, что неправильные аргументы будут приводить к ожидаемым ошибкам и т.д. и т.п.

Дальше можно перейти к тестированию самих сценариев работы с приложением.

Если речь о Модульном тестировании - замокать всё зависимости и пройтись по всем сценариям убедившись что всё идёт по плану. Суть моков в том что вы можете проверять что будет приходить в пустые методы, указывать что они будут возвращать, или при необходимости, бросать исключение.

Если хотите проверить что в итоге сохранится в базу - это уже будет ближе к EndToEnd тестированию. В таком случае можно поднять тестовую базу, и наполнить всеми необходимыми данными, а для проверок описать свои Assert-ы которые будут ходить в базу и проверять что там лежит.

Следует учитывать что если проект активно развивается - для него будет естественным переживать периодические рефакторинги, что с высокой вероятностью будет вынуждать к переписыванию Unit-тестов. Функциональные и EndToEnd тесты наоборот - позволят рефакторить всё что только можно, обновлять зависимости и PHP как только будут выходить stable версии, и при этом быть уверенным что тестируемые сценарии всё ещё работают как вы задумывали.

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

Названия в snake_case предпочтительней, потому что длинные названия методов в camelCase читать куда труднее.

Проблема должна пройти, если создавать моки в setUp, а в самих тестах уже конфигурировать.

В настройках PHPUnit путь к autoload файлу корректно прописан?