Как вы проектируете сложные системы с TDD?
Похожа на Имеется ли в виду, что TDD не думает о дизайне классов? TDD.
Согласно боулинг-игре Kata (версия «беседы», чья ссылка ускользает от меня на данный момент), TDD, похоже, игнорирует проектные решения, принятые на ранних этапах (отказ от объекта фрейма, объекта прокрутки и т. Д.). в этом примере хорошей идеей будет следовать тестам и игнорировать ваши первоначальные мысли о дизайне, но в более крупных проектах или проектах, в которых вы хотите оставить возможность для расширения / настройки, было бы лучше поместить вещи, которые вы делаете нет теста или нет Или я упускаю суть, и я должен был ожидать, что перезапишет части кода, когда я приду, чтобы протестировать новый раздел функциональности?
3 ответа
Я бы основал ваши тесты на вашем первоначальном дизайне. Во многих отношениях TDD - это процесс открытия. Вы можете ожидать, что либо подтвердите свой первоначальный выбор дизайна, либо обнаружите, что есть варианты лучше, которые вы можете сделать. Делайте столько предварительного дизайна, сколько вам удобно. Некоторым нравится летать мимо кресел, создавая высокоуровневый дизайн и используя TDD, чтобы конкретизировать дизайн. А другим нравится, чтобы все было сначала на бумаге.
Часть TDD - это рефакторинг.
Начните с грубой идеи дизайна, выберите первый тест и начните кодировать, проходя "зеленый" тест за тестом, позволяя дизайну появиться, похож он или нет на первоначальный дизайн. Сколько первоначального дизайна зависит от сложности проблемы.
Нужно быть внимательным, слушать и нюхать код, чтобы обнаружить возможности рефакторинга и запахи кода.
Строгое следование TDD и принципам SOLID сделает код чистым, тестируемым и гибким, так что его можно будет легко рефакторить, опираясь на модульные тесты как на строительные леса для предотвращения регрессии.
Я нашел три способа проектирования с помощью TDD:
- Позволить дизайну возникнуть естественным образом по мере устранения дублирования и сложности
- Создать идеальный дизайн заранее, используя макеты в сочетании с принципом единой ответственности
- Быть прагматичным в этом вопросе.
Прагматизм кажется лучшим выбором в большинстве случаев, поэтому вот что я делаю. Если я знаю, что определенный паттерн очень хорошо подойдет для решения моей задачи (например, MVC), я сразу же перейду к моделированию и буду считать, что он работает. В противном случае, если дизайн менее ясен, я позволю ему появиться.
Точка пересечения, в которой я чувствую необходимость рефакторинга возникающего дизайна, - это точка, в которой его перестает быть легко изменить. Если кусок кода не идеально спроектирован, но другой разработчик, столкнувшись с ним, может легко рефакторить его самостоятельно, это достаточно хорошо. Если код становится настолько сложным, что перестает быть очевидным для другого разработчика, пора его рефакторить.
Мне нравятся реальные варианты, и рефакторинг чего-то до совершенства кажется мне приверженностью дизайну без какой-либо реальной необходимости. Вместо этого я дорабатываю до "достаточно хорошо"; таким образом, если окажется, что мой проект неверен, я не потратил время зря. Предположите, что ваш дизайн будет неправильным, если вы никогда не использовали его раньше в подобном контексте.
Это также позволяет мне выпускать код гораздо быстрее, чем если бы он был идеальным. Однако именно мои попытки сделать код идеальным научили меня, где находится линия!