Проблема в том, что вы не хотите менять свой API для своих модульных тестов. Начните смотреть на свои юнит-тесты как на другого пользователя / потребителя вашего API. Как и разработчики, использующие эту библиотеку, модульные тесты предъявляют свои собственные требования. Когда вы увидите, что ваши модульные тесты являются потребителями вашего API, найдется пользователь, который использует эти геттеры, и он оправдает их.
Если невозможно изменить ваш API (например, если вы разрабатываете фреймворк многократного использования), сделайте API модульного тестирования внутренним и используйте InternalsVisibleToAttribute
, чтобы позволить вашей библиотеке тестирования получить доступ к внутренним методам вашего кода.
Оставляя в стороне модульные тесты, вы все равно можете подумать о том, чтобы получить эти свойства с геттерами, потому что наличие свойств без геттеров очень не интуитивно понятно разработчикам. В Руководстве по проектированию рамок даже есть правило против этого:
НЕ предоставляют свойства только для набора или
свойства с сеттером, имеющим
более широкий доступ, чем геттер.
Вы также можете принять это во внимание.
Удачи.