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

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

Что значит дизайн такой? Это логика приложения такая, как ее по другому задизайнить?

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

С моками можно по-разному тестировать. Правильно — в моках возвращаемое значение фиксировать, а не тестировать факт вызовы.
Хотя в некоторых случаях и факт вызова тоже может быть важен

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

Не понял, что понимается под вариантами. И почему ветвления не влияют.

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

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

С моками (стабами) я понимаю как это сделать — сайд-эффекты выделяются в интерфейсы (repo, external_service), мокаются, и далее вся логика проверяется как обычный юнит-тест.