Мы создаем фреймворк, который будут использовать другие разработчики, и на данный момент мы используем множество практик TDD. У нас везде есть интерфейсы и хорошо написанные модульные тесты, которые имитируют интерфейсы.
Однако сейчас мы подошли к моменту, когда некоторые свойства/методы входных классов должны быть внутренними и невидимыми для пользователей нашей среды (например, идентификатор объекта). Проблема в том, что мы не можем поместить эти поля/методы в интерфейс, поскольку интерфейс не описывает доступность.
Мы могли бы:
- По-прежнему используйте интерфейсы и преобразование в первую строку метода, но это, похоже, противоречит цели интерфейсов.
- Используйте классы в качестве входных параметров, нарушая правило TDD, согласно которому все должно быть интерфейсом.
- Обеспечьте еще один уровень, который выполняет некоторый перевод между общедоступными интерфейсами и внутренними интерфейсами.
Существует ли существующий шаблон/подход для решения этой проблемы? Что, по мнению специалистов по TDD, следует делать?
