Есть класс, у которого есть один основной метод:
1) берет на входе некий объект для доступа к разнообразной информации, стрим например
2) совершает над ним операции по вытаскиванию информации
3) обрабатывает информацию
4) выдает результат обработки.

Тестировать в лоб основной метод очень сложно — миллион вариантов начальных данных и набор финальных результатов,

Допустим действия 2,3 и 4 вынесены в отдельные промежуточные методы вспомогательных подклассов, т.о. их по отдельности можно оттестировать и заменить моками.

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

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

А теперь вопрос — как протестировать самый главный метод, который создает подклассы?

Вижу два варианта:
1) в конструктор всего класса передавать фабрики подклассов
2) фабрики создавать в виде моков, которые будут также выдавать моки подклассов.
3) проверять что главный метод вызвал методы фабрик
4) кодировать моки подклассов так, чтобы на них получался эталонный результат, а потом с ним сравнивать.

Но тут в пункте 4) огромный недостаток: он неявно тестирует практически весь класс целиком — это опять по сути исходная проблема.

Второй вариант — извращенский:
1)-3) такие же
4) Создать класс-наследник тестируемого класса
5) Оверрайдить второй метод (который изнутри вызывается тестируемым главным методом)
6) вызвать главный метод и убедиться, что он создал правильные подклассы и передал в наш оверрайденый метод.

В этом случае все методы отделены друг от друга и не надо строить всю цепочку от начальных тестовых данных до правильного финального результата.

Но это все-таки извращение какое-то, да и не всегда так получится.
Что можно в консерватории подправить?