Какова хорошая стратегия модульного тестирования цепочки вызовов публичных методов?
Тестируйте интерфейс, а не реализацию
Таким образом, у вас будут тесты для каждого из методов:public_a, public_b и public_c.
Когда вы надеваете шляпу тестера, вы не знаете, что public_b внутренне вызывает public_a - вы знаете только то, что должен делать public_b. Поэтому вам нужно убедиться, что public_a делает то, что должен делать, а public_b делает то, что должен делать, а public_c делает то, что должен делать.
В вашем случае тесты могут быть довольно повторяющимися - и это нормально. Вы проверяете функциональность. Однако в случае, если вы рефакторите один или несколько методов так, что цепочки методов больше не будет, ваши тесты уже написаны и должны отловить любые проблемы, связанные с рефакторингом.
Написание теста только для public_c может быть способом сэкономить некоторые усилия, но, как вы сказали, может работать только для подмножества случаев. И если вы обнаружите ошибку в тесте public_c, сможете ли вы узнать, была ли она вызвана логикой, специфичной для этого метода, или логикой в public_a или public_b? Видимо, нужно написать тесты для public_a и public_b, чтобы определить, где ошибка...
Прикрепляю к посту несколько видео по теме: