TDD и DDD, все еще понимая домен

Question

Когда вы начинаете новый проект с нуля, используя DDD, и все еще не очень комфортно с доменом, TDD стоит своей цены. Хотя вы все еще понимаете детали домена, вы обнаружите много вещей, которые вы сделали неправильно, например, метод, который имеет больше смысла в каком-то другом классе, или добавление / удаление параметров из конструктора, и многие другие изменения ,

Эти изменения ОЧЕНЬ часты, особенно в начале. Каждое изменение обычно (и мы надеемся) требует некоторых изменений в модульных тестах, что увеличивает стоимость изменений (что, как я уже говорил, все еще очень часто).

Мой вопрос: стоит ли TDD своих затрат, даже в тех случаях, когда все еще происходит много изменений, но есть надежда, что они станут менее частыми (например, как только мы получим лучшее представление о домене)?

Answer 1

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

Процесс понимания предметной области является процессом проектирования, и ему помогает TDD, который, как вы должны понимать, является техникой проектирования.

Тот метод, который имеет больше смысла в каком-то другом классе - вы быстро это понимаете, больше быстро, используя TDD, потому что первое, что вы делаете при написании метода, - это написание теста для него , Когда вы напишете этот тест, вы увидите, что (например) вам нужно передать много членов из другого класса, и это скажет вам - еще до того, как вы написали метод - «Эй, это относится к есть! "

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

Answer 2

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

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

Кроме того, если вы используете инструмент рефакторинга, такой как ReSharper или CodeRush, я обнаружил, что большинство ранних изменений действительно не так уж и плохи - только незначительные неудобства.

Answer 3

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

Есть и другие преимущества - вы знаете, что часть кода, которую вы не изменили, по-прежнему работает, поскольку она уже прошла тестирование. Даже если вы перепишите 50% кода, вы будете знать, что остальные 50% работают. Кроме того, вы знаете, что код тестируемый - вы разрабатывали его для тестирования все время. Часто бывает очень сложно добавлять модульные тесты в код, который не предназначен для их создания - обычно он написан так, что его очень сложно протестировать. Код, созданный для тестирования с самого начала, намного лучше.

Answer 4

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

TDD абсолютно полезен для понимания модели предметной области. TDD может использоваться, чтобы помочь определить модель предметной области, потому что это метод проектирования, как сказал Карл Манастер выше. TDD поможет вам определить, когда и где реализовать шаблон проектирования, если / когда объект определен в неправильной области и т. Д.

Answer 5

TDD должен помочь в этой ситуации, ИМХО. Часть полезности модульных тестов заключается в том, что они проверяют, что вы ничего не сломали во время рефакторинга. Да, некоторые изменения в коде потребуют изменений в тестах, но это должно помочь уточнить, что вы делаете, а не усложнить.

Answer 6

максимальная скорость изменения, большинство TDD становятся полезными. Проект с наборами требований в камне получит меньше от выполнения TDD по сравнению с проектом с высокой скоростью изменения.