TDD и UML вместе

Ответ 1

Итак, когда я сначала проектирую/создаю тест, как UML может вписаться? Будет ли это возможно сначала разработать классы, начиная с они создают классы скелета, от они генерируют модульные тесты, которые быть заполненным до фактического реализация UML pregenerated классов, будет ли этот подход нарушен весь TDD? Или есть другой способ что бы сохранить UML и TDD вместе?

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

Могут быть способы использовать как UML, так и TDD вместе для дизайна, но, как вы описали, вы делаете дизайн в UML, прежде чем TDD когда-либо получит шанс. Это не даст вам полной пользы от TDD.

Ответ 2

Цикл TDD - это тест, код, рефактор, (повтор), а затем отправка. Как следует из названия TDD, процесс разработки управляется путем тестирования, в частности, это означает сначала писать тесты до разработки или написания кода.

Первый абзац - чисто определение... из того, как Kent Beck определяет TDD... или как Википедии в целом понимают TDD... Я думал, что необходимо подкрепить суть этого определения, потому что я не уверен, что все действительно обсуждают тот же TDD, или если другие действительно понимают подразумевает [наиболее важную часть или определение] TDD, последствия написания тестов сначала. Другими словами, я думаю, что больше внимания в ответах на этот вопрос должно углубиться в TDD, а не объяснять предвзятость для UML. Длительная часть моего ответа связана с моим мнением об использовании UML для поддержки TDD... UML - это всего лишь язык моделирования, который, конечно же, не требуется для TDD; это может мешать, если применить ненадлежащим образом... но UML может помочь с пониманием требований к написанию тестов, как моделирование может помочь рефактору при необходимости и как сбор артефактов процесса ускоряет документацию отправленного кода. Я бы приветствовал любые комментарии, критические замечания или предложения, но, пожалуйста, не проголосуйте за мой ответ вверх или вниз, потому что вы согласны или не согласны с первым абзацем... Сокращение TDD - это разработка, основанная на тестах, которая означает Test-First Development,

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

UML-диаграммы - это одна из форм требований, вводимых в TDD. Не единственное, но, вероятно, лучше, чем письменные спецификации, если доступны люди, которые хорошо осведомлены о создании диаграмм UML. Часто лучше работать с визуальными диаграммами для лучшей коммуникации при изучении проблемного домена [с пользователями/клиентами/другими системными поставщиками] во время сеансов моделирования требований до внедрения... где имитация производительности необходима для действительно понимания требований (например, сетевые взаимодействия CANbus ); часто бывает идеальным, если мы можем работать со спецификационным языком или инструментом CASE, например Rhapsody или Simulink RT Workshop, который может быть исполняемым, модульным и полным... UML не обязательно является частью TDD, но он является частью синтеза дизайна подхода, предполагает затрачивать больше усилий на понимание того, что требуется сначала, прежде чем писать какой-либо код [и затем тратить время на то, чтобы продать этот код кому-то, кто заботится]; как правило, больше внимания уделяется пониманию системных требований, закладывает основу для более эффективных, продуктивных гибких итераций TDD.

Рефакторинг - это улучшение дизайна - очистка работы, протестированный код, чтобы упростить его, упростить. Вы хотите максимально затянуть его, чтобы удалить запутанные путаницы, где ошибки могут скрываться или появляться в будущих выпусках - вы не рефакторируете, потому что клиент требует этого; вы рефакторинг, потому что дешевле отправлять чистый код, а не продолжать оплачивать расходы на поддержку/поддержание сложного беспорядка. Как правило, большая часть TDD более ориентирована на код; но вы можете использовать UML для просмотра большей области действия или сделать шаг назад, чтобы посмотреть на проблему, например. создавая диаграмму классов, чтобы помочь идентифицировать [отсутствующие] тесты или возможные рефакторинги. Это не то, что вам нужно было бы поручить или хотеть делать на общей основе, но там, где это необходимо.

Последний шаг, "корабль" - серьезный шаг... "корабль" не сокращает "бросить его через стену и забыть, потому что хороший код не нуждается в поддержке" или "отказаться" и надеяться, что там больше нет итераций ". С точки зрения финансов или бизнеса, судоходство является самым важным шагом TDD, потому что именно там вы получаете деньги. Судоходство связано с" переключением передач ", поскольку оно включает в себя системную интеграцию, подготовку к поддержке и обслуживанию, подготовку к следующему раунду разработки и т.д. Основное использование диаграмм UML будет заключаться в том, чтобы сообщать [в абстрактных терминах], как это делает код что он делает... UML полезен, потому что, надеюсь, диаграммы являются артефактом требований и процессов разработки; не нужно начинать с нуля, когда код отправляется... как инструмент связи, UML был бы подходящим для уменьшения ошибок интеграции многомодульных систем, больших проектов, которые могли бы включать модули, написанные на разных языках, сети встроенных систем, где разные компании должны сотрудничать в критически важных системах, но нуждаются в том, чтобы абстракция была скупой или защищала их" фирменные знания".

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

Ответ 3

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

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

Как только ваш дизайн появился в результате применения TDD, вы можете сообщить об этом проекте с использованием UML. Если вам не нужно общаться (например, если вы единственный разработчик), вам, возможно, не нужен UML.

Некоторые люди считают анализ домена (определение ключевых существительных, глаголов и прилагательных и построение базовой онтологической модели) как часть методологии UML, отраженной в прецедентах и ​​диаграммах ER... Это может быть полезно сделать до вы переходите в красный/зеленый/рефракторный цикл TDD. Опять же, строго говоря, это DDD (Domain Driven Design), а не UML как таковой.

Ответ 4

Если вы разрабатываете классы с использованием UML, вы разрабатываете, как вы думаете, код будет выглядеть. Но то, что вы создаете с помощью TDD, - это реальность.

Оставьте UML до конца, чтобы документировать результаты кода, созданного с помощью TDD.

Ответ 5

Или есть ли другой способ, который бы поддерживал UML и TDD?

UML и TDD прекрасно сочетаются вместе:

• Сделать первоначальный дизайн в UML - он не обязательно должен быть полным, просто согласованным, автономным
• Создайте пустые тесты. Этот шаг можно также автоматизировать.
• Все тесты сначала потерпят неудачу, как требуется TDD (поскольку сгенерированный код из UML не имеет никакого кода)
• Начните писать тесты для каждого класса
  • Начните с классов, которые не имеют большого количества ассоциаций, если вы уверены в своей архитектуре программного обеспечения и навыках UML (нет, вы не делаете водопад, но иногда вы просто знаете, что делаете, - вы знаете, домен приложения уже или вы использовали экспертные знания на шаге 1).
  • Начните с классов, которые имеют множество ассоциаций ( "центральных классов" ), если вы НЕ уверены в своем понимании области приложения - это облегчит устранение как можно скорее плохих проектных решений, потому что вы заметите их как можно раньше
• ... Тесты все еще не работают
• Параллельно с каждым тестируемым устройством (шаг 4) запишите реализацию внутри пустых тел метода. НЕ изменяйте имена классов, интерфейсов или методов или сигнатуры параметров. Вам разрешено добавлять методы private helper, а не больше
• Если на шаге 6 (который запускается в тандеме с шагом 4) вы понимаете, что вам нужно внести изменения в дизайн:
  • Перейдите к шагу 1 и уточните UML, а затем снова сгенерируйте код (хорошие инструменты UML не будут перезаписывать вашу реализацию). Внимание: не вводите новые классы. Вы хотите завершить шаг 13 в течение нескольких недель.
  • Повторно запустите тесты и исправьте те из них, которые ранее были ОК
  • Продолжайте то, что вы оставили на шаге 6
• Перейдите к шагу 6, если не все тесты класса проходят
• Перейдите к тестированию компонентов, пакетов и подсистем.
• Добавьте развертывание в UML и разверните его в среду интеграции (http://en.wikipedia.org/wiki/Development_environment_%28software_development_process%29)
• Перейти к интеграционным тестам
• Пройдите этап тестирования /QA
• Пройдите проверку приёма пользователей
• Повторите предыдущие шаги по мере необходимости (в соответствии с вашим итеративным процессом разработки).
• ... месячные пропуски
• Развертывание версии 1.0.0 для производства

Не пытайтесь выполнить множество проектных решений на шаге 1 или после повторений шага 1 (уточнение дизайна). Вы хотите завершить шаг 13 на первой итерации через несколько недель.

Ответ 6

UML - это часть дизайна, конечно.

Я бы использовал его только в системе, с которой я столкнулся. Рендеринг тестовых классов в UML мне кажется смешным.

Я бы использовал его, чтобы получить общее представление о том, что я создаю. Затем я начну с TDD, чтобы реализовать его.

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