Разве TDD означает не думать о дизайне классов?

Я делаю ролевую игру для удовольствия и пытаюсь использовать TDD при ее разработке. Многие из примеров TDD, которые я вижу, сосредоточены на создании теста сначала, а затем на создании объектов, необходимых для прохождения теста.

Например:

[Test]
public void Character_WhenHealthIsBelowZero_IsDead()
{
   // create default character with 10 health
   Character character = new Character();
   character.SubtractHealth(20);
   Assert.That(character.IsAlive, Is.EqualTo(false));
}

Поэтому на основе этого я создам класс символов и соответствующие свойства/методы. Это кажется прекрасным, и все, но должен ли мой классный дизайн действительно выйти из постоянного совершенствования моих тестов? Это лучше, чем сопоставление возможных объектов, которые моя игра будет необходима раньше времени? Например, я обычно думаю о базовом классе символов, а затем подклассах, таких как Wizard, Fighter, Theif.

Или сбалансированный подход - путь? Один, где я сопоставляю возможные классы и иерархию, которые мне понадобятся, но сначала пишу тесты, чтобы убедиться, что они действительно нужны?

Ответ 1

Должен ли мой класс дизайн действительно выйти постоянно совершенствовать мои тесты?

Да.

Знает ли TDD не думать о классе дизайн?

Абсолютно нет. Это означает думать о дизайне класса во время написания ваших тестов и остальной части вашего кода. Дизайн класса работает в течение жизненного цикла Red-Green-Refactor TDD.

Ответ 2

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

Похоже, вы делаете это назад.

Ваши действия должны быть:

Создайте модель своего домена
Создайте свои классы
Напишите несколько тестов
Реализация некоторой логики классов
Рефакторинг ваших классов, чтобы сделать их более проверяемыми, если это необходимо.
Повторите шаги 3-5

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

Сбалансированный подход - это путь.

Тем не менее, баланс управляется необходимостью тестирования.

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

Для того, чтобы ваши тесты даже компилировались, вам нужны определённые определения классов. Им не нужно работать, но они должны скомпилировать.

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

Ответ 7

TDD - это дизайн! Таким образом, TDD вы будете уверены, что ваш дизайн полностью проверен.

Кроме того, "сбалансированный подход" - это путь ИМО. Вы уже знаете архитектуру высокого уровня, и TDD будет проверять эту архитектуру.

EDIT: Хотя, если вы хотите просто практиковать TDD, я бы не стал "сбалансированным подходом". Я бы просто сделал TDD с "малышами" и, возможно, кодировал Dojos

Ответ 8

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

Оба подхода полезны. Даже хардкорные ревнители TDD иногда используют карандаш-бумагу (или, возможно, доску), а типы BDUF-ueber-alles будут избивать случайный прототип. Тогда возникает вопрос, где вы, как правило, падаете: обдумываете или более практичны?