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

В процессе итерации по массиву - собирайте новый, индексируя его элементы по идентификатору свойства.

На примере Symfony. Доки:
Автоматическое внедрение зависимостей в конструктор - Autowiring
Автоматическое внедрение зависимостей в аргументы методов контроллеров - Argument Resolvers

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

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

Убедится в корректности конфигурирования роутов можно командой:
php bin/console debug:router

Дока

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

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

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

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

Для изолированной отладки микросервисов можно использовать тесты.

Можно сразу писать функциональный тест на проблемный кейс. Его и проверять будет проще в процессе фикса, и можно оставить в проекте и быть более уверенным в том что проблема не повториться.

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

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

for($i = 0; $i <= 5; $i++){
Почему пять, почему не десять?
for($j = 0; $j < 3; $j++){
А почему не пять?

Предложил бы использовать foreach, но ни по вопросу, ни по коду не понятно каким образом наборы этих объектов должны мержиться.

получилась какая-то чушь

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

Run > Edit Configurations... > Add New Configuration

Тут можно хранить команды, и запускать их через GUI самого шторма.

Разбить по отдельным сервисам*, в том числе и содержимое commonMethod вынести в отдельную структуру, которую использовать в сервисах с methodFirst и methodSecond.

*это не обязательно должны быть сервисы

Если тут так и не будет лаконичного объяснения - советую поискать
ответы на эти вопросы в книге:
Implementing Domain Driven Design, Vaughn Vernon
Там есть целые разделы посвященные как моделям так и репозиториям.

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

Это не JSON, вот и не работает.

Если не боитесь нагружать модель бизнес-логикой - можно сделать метод:
readBy(User $user)
И уже внутри проверять начальник это или подчинённый, и проставлять соответствующий флаг.