Здравствуйте, Буравчик, Вы писали:

Б>Кстати, что делаете если параметров много (как в примере)? Выделяете под них структуру для хранения?

Выделяю. Так проще добавлять чего нибудь в будущем.

Б>2. Про логику

Б>Ниже пример того, что хотим протестировать. Есть обращение к БД и внешним сервисам. Как это будет протестировано?

Если дизайн именно такой, и надо вдруг покрыть это тестами, то вариантов не много
1. интеграционные тесты с какой то базой
2. разного сорта моки

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

Б>Самый главный вопрос — как будет протестировано ветвление (if-ы, их может быть много).

Это ничего не меняет — вашем дизайне вариантов нету, и наличие ветвлений их не увеличит.

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

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