Как вы балансируете Framework / API Design и TDD?

Question

Мы создаем фреймворк, который будет использоваться другими разработчиками, и на данный момент мы используем много методов TDD. У нас везде есть интерфейсы, и у нас есть хорошо написанные модульные тесты, которые имитируют эти интерфейсы.

Однако сейчас мы достигли точки, когда некоторые свойства / методы входных классов должны быть внутренними и невидимыми для наших пользователей инфраструктуры (например, идентификатор объекта). Проблема в том, что мы не можем поместить эти поля / методы в интерфейс, так как интерфейс не описывает доступность.

Мы могли бы:

1. В первой строке метода все еще используются интерфейсы и upcast, но, похоже, это противоречит назначению интерфейсов.
2. Использование классов в качестве входных параметров - нарушение правила TDD о том, что все должно быть интерфейсами
3. Предоставляет другой уровень, который выполняет некоторый перевод между общедоступными интерфейсами и внутренними интерфейсами

Существует ли существующий шаблон / подход для решения этой проблемы? Что, по словам людей TDD, следует сделать?

Answer 1

Во-первых, нет общего правила TDD, которое говорит, что все должно быть интерфейсом. Это происходит от определенного стиля, который практикуется не каждым TDDer. Смотри http://martinfowler.com/articles/mocksArentStubs.html

Во-вторых, вы испытываете дихотомию публикация против опубликованной . Наша команда «решила» эту проблему, представив аннотацию @Published, которая отображается в документации API. Насколько я знаю, Eclipse использует соглашения об именах. К сожалению, я не знаю действительно хорошего решения проблемы.

Answer 2

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

Удачи.

Answer 3

Звучит так, будто вы хотите, чтобы у вашего класса была инъекция зависимостей . Поисковый стек тоже Затем вы можете установить этот идентификатор по своему выбору либо в конструкторе, либо через установщик.

[1л