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

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

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

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Затем вы можете сделать свой пакет методов приватным.