Юнит-тесты должны в 95% случаев проверять только открытую поверхность класса. Если вы тестируете что-то под прикрытием, это тестирует детали реализации, которые по своей сути хрупки, потому что вы должны иметь возможность легко менять реализацию и при этом тесты работать. Он не только хрупок, но вы также можете испытать то, что на самом деле невозможно в сценариях запланированного использования, что является пустой тратой времени.
Если точка доступа, которую вы хотите добавить, состоит в том, чтобы просто проверить, имела ли функция желаемый эффект, ваш класс может нарушить другой принцип, который заключается в том, что класс, подобный конечному автомату, должен всегда прояснять, в каком состоянии его, если это влияет на то, что происходит, когда люди взаимодействуют с классом. В этом случае было бы правильно предоставить доступ только для чтения. Если это не влияет на поведение класса, вернитесь к моему предыдущему биту о деталях реализации.
И как вы правильно сказали, загромождение публичной поверхности класса неиспользуемыми предметами также нежелательно по своим собственным причинам.
Если бы у меня было , чтобы выбрать между аксессорами и френдингом в вашем случае, я бы выбрал френдинг, просто потому что вы владеете своим тестом и можете изменить его в крайнем случае. Вы не можете владеть кодом клоуна, который найдет способ использовать ваши дополнительные средства доступа, и тогда вы застрянете.