TDD и DDD, все еще понимая домен
Вызывая abs вместо std::abs, вы просто используете abs из C
.
6 ответов
Если вы находитесь на этапе, когда вы все еще проектируете компоненты модели предметной области на относительно высоком уровне, то вам пока не следует писать модульные тесты. Вам необходимо иметь представление о предметной области и обязанностях ваших классов, прежде чем вы сможете начать писать какой-либо код.
Если вы находитесь в точке, где вы возитесь с конструкторами и параметрами в своих классах, то TDD не должен можно рассматривать как затраты - это помогает вам обнаруживать и исправлять проблемы в вашем дизайне. Это инвестиции в лучшую объектную модель и меньшее обслуживание в будущем.
Кроме того, если вы используете инструмент рефакторинга, такой как ReSharper или CodeRush, я считаю, что большинство ранних изменений действительно не так уж плохи - просто незначительные неудобства.
Думаю, да. Часть разработки через тестирование заключается в том, что вы создаете только то, что вам нужно, - только то, что требуется для прохождения тестов. Итак, если вам нужно что-то изменить в коде из-за более четкого понимания предметной области, вам, возможно, придется меньше менять с помощью подхода TDD, чем без него, потому что вы не потратили время на создание ненужных вещей.
Есть и другие преимущества. а также - вы знаете, что часть кода, которую вы не изменили, все еще работает, поскольку она уже прошла тесты. Даже если вы перепишете 50% кода, вы будете знать, что остальные 50% работают. Кроме того, вы знаете, что код можно тестировать - вы все время создавали его для тестирования. Часто бывает очень сложно добавлять модульные тесты в код, который не предполагал их наличия - это ' s обычно пишутся так, что их очень трудно проверить. Код, предназначенный для тестирования с самого начала, намного лучше.
Пока вы все еще понимаете детали домена, вы выясните много вещей, которые вы сделали неправильно, например метод, который имеет больше смысла в некоторых другой класс, или добавление / удаление параметры из конструктора и много других изменений.
Процесс понимания предметной области - это процесс проектирования, и ему помогает TDD, который, как вы должны понимать, является техникой проектирования.
Этот метод имеет больше смысла в какой-то другой класс - вы быстро поймете это, еще быстро, используя TDD, потому что первое, что вы делаете при написании метода, - это пишете для него тест. Когда вы напишете этот тест, вы увидите, что (например) вам нужно передать много членов из другого класса, и это скажет вам - еще до того, как вы даже напишете метод - «Эй, это относится к там! "
Используйте TDD, чтобы уменьшить отток, который вы описываете. Это не устранит его, но уменьшит, потому что вы делаете дизайн на микро, по запросу, по мере необходимости. Это своевременный дизайн.
TDD должен помочь в этой ситуации, ИМХО. Частично полезность модульных тестов заключается в том, что они проверяют, что вы ничего не сломали во время рефакторинга. Да, некоторые изменения в коде потребуют внесения изменений в тесты, но это должно помочь прояснить, что вы делаете, а не усложнить задачу.
As stated above TDD is more about testing and proving your design and less about Unit Testing. TDD is NOT Unit Testing, but Unit Tests can evolve from tests created in your TDD.
TDD is absolutly helpful in understanding the Domain model. TDD can be used to help define the Domain model causei it is a design technique as Carl Manaster stated above. TDD will help you recognize when and where to implement a design pattern, if / when an object is being defined in the wrong domain etc.
наибольшая скорость изменения, наибольшее количество TDD становится полезным. Проект с каменными требованиями получит меньше от выполнения TDD по сравнению с проектом с высокой скоростью изменения.