Слишком много общедоступных методов, вызванных разработкой, управляемой тестами

Question

Очень специфический вопрос от новичка к TDD:

Я разделяю свои тесты и мое приложение на разные пакеты. Таким образом, большинство методов моего приложения должны быть общедоступными, чтобы тесты могли их получить. По мере продвижения, становится очевидным, что некоторые методы могут стать частными, но если я сделаю это изменение, тесты, которые обращаются к ним, не будут работать. Я пропускаю шаг, или делаю что-то не так, или это всего лишь одно падение TDD?

Answer 1

Это не падение TDD, а скорее подход к тестированию, который считает, что вам нужно тестировать каждое свойство и каждый метод. На самом деле, вам не следует беспокоиться о частных методах при тестировании, потому что они должны существовать только для облегчения некоторой общедоступной части API.

Никогда не меняйте что-либо с частного на общедоступное для тестирования!

Вы должны пытаться проверить только публично видимое поведение. Остальные детали реализации, и вы специально хотите избежать их тестирования. TDD предназначен для предоставления вам набора тестов, которые позволят вам легко изменять детали реализации, не нарушая тесты (изменяя поведение).

Допустим, у меня есть тип: MyClass, и я хочу проверить метод DoStuff. Все, что меня волнует, это то, что метод DoStuff делает что-то значимое и возвращает ожидаемые результаты. Для достижения этой цели может потребоваться сотня частных методов, но мне все равно, как потребителю этого метода.

Answer 2

Вы не указываете, какой язык вы используете, но, безусловно, в большинстве из них вы можете поставить тесты таким образом, чтобы иметь более привилегированный доступ к классу. Например, в Java тест может находиться в одном пакете, а фактический файл класса находится в другом каталоге, поэтому он отделен от рабочего кода.

Однако, когда вы выполняете настоящий TDD, тесты определяют дизайн класса, поэтому, если у вас есть метод, который существует только для проверки некоторого подмножества функций, вы, вероятно, (не всегда) делаете что-то не так, и вам следует посмотрите на методы, такие как внедрение зависимостей и насмешки, чтобы лучше руководить вашим дизайном.

Answer 3

Здесь часто встречается старая поговорка «TDD - это дизайн». У класса, в котором слишком много открытых методов, вероятно, слишком много обязанностей - и тот факт, что вы тестируете его, только обнажает это; это не вызывает проблемы.

Когда вы попадаете в эту ситуацию, лучшее решение часто состоит в том, чтобы найти некоторое подмножество открытых методов, которые можно извлечь в новый класс («класс ростков»), а затем дать вашему исходному классу переменную экземпляра проросшего учебный класс. Публичные методы заслуживают того, чтобы быть публичными в новом классе, но теперь они - по отношению к API оригинального класса - закрытые. И теперь у вас есть лучшая приверженность SRP, более слабая связь, более низкая когезия - лучшая конструкция.

Все потому, что TDD показал особенности вашего класса, которые в противном случае могли бы проскользнуть под радар. TDD - это дизайн .

Answer 4

По крайней мере в Java рекомендуется использовать два дерева исходных кодов, одно для кода и одно для тестов. Таким образом, вы можете поместить свой код и ваши тесты в один и тот же пакет, пока они находятся в разных каталогах:

src/org/my/xy/X.java
test/org/my/xy/TestX.java

Тогда вы можете сделать ваш пакет методов приватным.