TDD и UML вместе
Я плохо знаком с подходом TDD, таким образом, я задаюсь вопросом, испытал ли кто-либо остроумие, это могло бы просветить меня немного. Я хотел бы добраться, некоторые ведут, как использовать UML и методологию TDD вместе.
Я привык к: Дизайн с UML-> Генерирует скелетные классы (и затем сохраните его, синхронизировался)-> Реализация и наконец Тест. Я должен признать, что тестирование части было худшим, таким образом, я начал искать что-то еще - TDD. Таким образом, у меня есть некоторые общие знания, что является ими о, но прежде чем я продолжу двигаться далее, мне интересно, зная, как они сочетаются с разработкой программного обеспечения особенно UML.
Таким образом, когда я сначала разрабатываю/создаю тест, как UML может вписаться? Было бы возможно разработать классы сначала, от них создают скелетные классы, от них генерируют Модульные тесты, которые были бы "заполнены", прежде чем фактическая реализация UML предварительно генерировала классы, это приблизится к повреждению целый TDD? Или есть ли какой-либо другой путь, который сохранил бы UML и TDD вместе?
4 ответа
Итак, когда я впервые разрабатываю / создаю тест, как может вписаться UML? Будет ли это возможно сначала спроектировать классы, начиная с они создают классы скелетов, из они генерируют модульные тесты, которые быть "заполненным" до фактического реализация предварительно сгенерированного UML классы, не сломается ли этот подход весь TDD? Или есть другой способ что бы сохранить UML и TDD вместе?
Если вы создадите весь скелетный класс - я предполагаю, что вы имеете в виду класс со всеми определенными, но пустыми методами - перед написанием вашего первого теста, тогда я бы сказал, что вы не выполняете TDD, и потеряете преимущества TDD. По мере того, как мы делаем TDD - Test-Driven Design , наши тесты постепенно приводят нас к следующим элементам - методам и классам - которые нужны нашей программе. Если вы заранее определили, предварительно указали в UML, каковы ваши классы и методы, большая часть вашего дизайна уже сделана, и либо ваше последующее развитие ограничено в соответствии с ним, либо вы потратили впустую усилия, которые последующая работа будет отменена.
Могут существовать способы совместного использования UML и TDD для проектирования, но, как вы описали, вы выполняете дизайн в рамках UML, прежде чем TDD когда-либо получит шанс. Это не даст вам всех преимуществ TDD.
Если вы проектируете классы с использованием UML, вы проектируете то, что, по вашему , , будет выглядеть код. Но то, что вы создаете , используя TDD, - это реальность.
Оставьте UML до конца, чтобы задокументировать результаты кода, созданного с помощью TDD.
UML, конечно же, является частью дизайна.
Я бы использовал его только в той системе, в которой оказался. Отрисовка тестовых классов в UML кажется мне нелепой.
Я бы использовал это, чтобы получить общее представление о том, что я создавал. Затем я бы начал с TDD, чтобы реализовать его.
Что касается синхронизации, я бы получил инструмент UML, способный импортировать и экспортировать. Я бы больше беспокоился о коде и меньше о UML. Это полезно для записи ваших мыслей и их последующего документирования, но не более того. Я всегда предпочитаю рабочий, проверенный код диаграммам.
Хотя некоторые люди думают, что UML - это методология проектирования, это, прежде всего, инструмент коммуникации. Отсюда и название «Единый язык моделирования». Идея состоит в том, чтобы иметь общий словарь (форм), который вы можете вставить в книгу, и все поймут.
TDD, с другой стороны, представляет собой методологию проектирования, способ построения системы, начиная с ее интерфейса и ее потребителя, и только затем добавляя реализацию.
Как только ваш дизайн появился в результате применения TDD, вы можете передать этот дизайн с помощью UML. Если вам не нужно общаться (например, если вы единственный разработчик), возможно, вам не нужен UML.
Некоторые люди считают анализ предметной области (определение ключевых существительных, глаголов и прилагательных и построение базовой онтологической модели) частью методологии UML, отраженной в прецедентах и диаграммах ER ... Это может быть полезно сделать раньше вы переходите в цикл красный / зеленый / рефакторинг TDD. Опять же, строго говоря, это DDD (Domain Driven Design), а не UML как таковой.