Очень конкретный вопрос от новичка до TDD:
Я разделяю свои тесты и свое приложение на разные пакеты. Таким образом, большинство моих методов приложения должны быть общедоступными для тестирования, чтобы получить к ним доступ. По мере того, как я прогрессирую, становится очевидным, что некоторые методы могут стать частными, но если я сделаю это изменение, тесты, которые будут обращаться к ним, не будут работать. Я пропустил шаг или сделал что-то не так, или это просто одно падение TDD?
Это не падение TDD, а скорее подход к тестированию, который считает, что вам нужно проверить каждое свойство и каждый метод. На самом деле вам не нужно заботиться о частных методах при тестировании, потому что они должны существовать только для облегчения части публичной части API.
Никогда не изменяйте что-то от частного к публичному в целях тестирования!
Вы должны пытаться проверить только видимое поведение. Остальные - детали реализации, и вы специально хотите избежать их тестирования. TDD предназначен для того, чтобы дать вам набор тестов, которые позволят вам легко изменить данные о реализации, не нарушая тесты (изменение поведения).
Предположим, у меня есть тип: MyClass, и я хочу протестировать метод DoStuff. Все, о чем я забочусь, это то, что метод DoStuff делает что-то значимое и возвращает ожидаемые результаты. Он может вызвать сотни частных методов, чтобы добраться до этого момента, но мне все равно, как потребитель этого метода.
Вы не указываете, какой язык вы используете, но, конечно, в большинстве из них вы можете поставить тесты таким образом, чтобы иметь более привилегированный доступ к классу. Например, в Java тест может быть в одном пакете с фактическим файлом класса, находящимся в другом каталоге, поэтому он отделен от производственного кода.
Однако, когда вы делаете настоящий TDD, тесты управляют дизайном класса, поэтому, если у вас есть метод, который существует только для проверки некоторых подмножеств функциональности, вы, вероятно, (не всегда) делаете что-то неправильно, и вы должны посмотрите на такие методы, как инъекция зависимостей и насмешка, чтобы лучше руководствоваться вашим дизайном.
Вот где часто появляется старая поговорка "TDD о дизайне". У класса со слишком многими общественными методами, вероятно, слишком много обязанностей - и тот факт, что вы управляете тестированием, только раскрывает это; это не вызывает проблемы.
Когда вы находите себя в этой ситуации, лучшим решением является поиск некоторого подмножества общедоступных методов, которые можно извлечь в новый класс ( "sprout class" ), а затем дать вашему первоначальному классу переменную экземпляра проросшего класс. Публичные методы заслуживают того, чтобы быть публичными в новом классе, но теперь они - в отношении API исходного класса - private. И теперь у вас есть лучшее сцепление с SRP, ослабление сцепления, более низкое сцепление - лучший дизайн.
Все, потому что TDD открывал функции вашего класса, которые иначе могли бы скользнуть под радаром. TDD - это дизайн.
Как минимум в Java, хорошая практика состоит в том, чтобы иметь два дерева источников, один для кода и один для тестов. Таким образом, вы можете поместить свой код и свои тесты в один и тот же пакет, пока они все еще находятся в разных каталогах:
src/org/my/xy/X.java
test/org/my/xy/TestX.java
Затем вы можете сделать свой пакет методов приватным.