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

Question

Я делаю ролевую игру для развлечения и пытаюсь использовать 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.

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

Answer 1

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

Да.

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

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

Answer 2

Я думаю, вы упускаете из виду TDD. TDD не о написании тестов, а о разработке ваших классов для тестирования. Это, естественно, приводит к лучшему проектированию и реализации.

Звучит так, будто вы делаете это задом наперед.

Ваши шаги должны быть:

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

Однако баланс определяется необходимостью тестирования.

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

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

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