Как вы проектируете сложные системы с TDD?

Question

Похоже на Означает ли TDD не думать о дизайне класса? , у меня возникают проблемы с размышлениями о том, где традиционная стадия «дизайна» вписывается в TDD.

Согласно боулинг-игре Kata(версия «разговора», чья ссылка ускользает от меня на данный момент) TDD, похоже, игнорирует проектные решения, принятые на ранних этапах (отказ от объекта фрейма, объекта прокрутки и т. д.).Я вижу в этом примере, что было бы хорошей идеей следовать тестам и игнорировать ваши первоначальные мысли о дизайне, но в более крупных проектах или проектах, в которых вы хотите оставить возможность для расширения / настройки, было бы лучше поместить вещи вчто у вас нет теста, или вы не нуждаетесь в нем немедленно, чтобы избежать трудоемких переписываний позже?

Короче говоря - сколько дизайна слишком много при выполнении TDD и сколькоДолжен ли я следовать этому проекту, когда я пишу тесты и код для их прохождения (игнорируя мой дизайн, чтобы беспокоиться только о прохождении тестов)?

Или я ни о чем не беспокоюсь, и код, написанный просто для того, чтобы следовать тестам, не (на практике) сложно переписать или переработать, если тебя раскрашивают в угол?В качестве альтернативы, я упускаю суть, и я должен ожидать, что перепишет части кода, когда я приду, чтобы протестировать новый раздел функциональности?

Answer 1

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

Часть TDD - рефакторинг.

Answer 2

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

В контексте «Разработка» использование TDD гарантирует, что вы пишете тестируемый код, который дает все преимущества, упомянутые в TDD (обнаружение ошибок на ранних этапах, высокий уровень кода: коэффициент покрытия тестов, более простой рефакторинг в будущем и т. Д. и др.)

Но в «Проектировании» больших сложных систем TDD особо не учитывает следующие проблемы, присущие архитектуре системы

1. (Техника для) Производительность
2. Безопасность
3. Масштабируемость
4. Наличие
5. (и все другие «способности»)

(т. Е. Все вышеперечисленные проблемы волшебным образом не проявляются через «сначала написать неудачный тестовый пример, а затем рабочую реализацию, Refactor - lather, rinse, repeat ...»).

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

• Некоторые из вышеперечисленных соображений конкурируют друг с другом и требуют осторожных компромиссов, которые просто не «возникают» при написании множества юнит-тестов.

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

Мне еще предстоит встретить довольно сложную часть программного обеспечения (например, компилятор, базу данных, операционную систему), которая была выполнена в стиле Test Driven Design . В следующей статье блога об этом очень хорошо говорится ( Компиляторы, TDD, Mastery )

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

Answer 3

Начните с грубой идеи проекта, выберите первый тест и начните кодировать, переходите к зеленому тесту после теста, позволяя появиться дизайну, похожему или не похожему на первоначальный проект.Степень первоначального проектирования зависит от сложности проблемы.

Нужно быть внимательным, слушать и анализировать код, чтобы обнаружить возможности рефакторинга и запахи кода.

Строго следуя принципам TDD и SOLID , код будет чистым, тестируемым и гибким, поэтому его можно будет легко реорганизовать, используя модульные тесты в качестве строительных лесов для предотвращения регрессии.

Answer 4

Я нашел три способа создания дизайна с помощью TDD:

• Разрешить естественному появлению дизайна, когда устранены дублирование и сложность
• Создайте идеальный дизайн заранее, используя макеты в сочетании с принципом единой ответственности
• Будьте прагматичны в этом.

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

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

Мне нравятся «Реальные параметры», и рефакторинг чего-либо до совершенства напоминает мне приверженность дизайну без реальной необходимости в этом. Вместо этого я рефакторинг на «достаточно хорошо»; таким образом, если мой дизайн окажется неправильным, я не трачу время впустую. Предположим, что ваш дизайн будет неправильным, если вы никогда не использовали его ранее в подобном контексте.

Это также позволяет мне выводить код намного быстрее, чем если бы он был идеальным. Сказав это, мои попытки усовершенствовать код научили меня, где находится строка!