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));
}
Таким образом на основе этого я создам класс символов и соответствующие свойства/методы. Это кажется прекрасным, и почти мой класс должен разработать действительно вышедшийся непрерывное совершенствование моих тестов? Это лучше, чем планирование возможных объектов, в которых моя игра будет нужна заранее? Например, я обычно думал бы о классе основного символа, затем разделяю на подклассы, такие как Мастер, Борец, Theif.
Или действительно ли сбалансированный подход является способом пойти? Тот, где я планирую возможные классы и иерархию, мне будет нужно, но пишущие тесты сначала для проверки они на самом деле необходимы?
8 ответов
Если мой класс дизайн действительно выйдет постоянного переработки моих тестов?
Да.
TDD означает не думать о классе Дизайн?
Абсолютно нет. Это означает, что думает о дизайне класса в процессе написания ваших тестов, а остальная часть вашего кода. Дизайн класса находится в игре во всей жизненном цикле Red-Green-Refaxtor TDD.
Я думаю, что это обычно предполагается (даже тестами TDD), что программист, разработающий приложение, написав тесты, уже знает что-то о дизайне и архитектуре. В противном случае вы можете просто нарисовать себя в программировании хаоса и анархии, написав тесты на отказ от любых принципов проектирования.
Следовательно, разработчик, написание приложений «Испытания сначала» уже имеет справедливую идею о том, как будет выглядеть его конечная структура класса, и это зрение направляет его, когда он пишет свои тесты.
Я согласен с методом Machine.config. Тем не менее, более простой способ сделать это было бы создать каталог где-то в вашей файловой системе с зашифрованным файлом XML. Используйте DPAPI, например, а затем просто создайте обычный класс, который читает, расшифровывает файл и возвращает строку подключения. Не забудьте иметь метод отставания, чтобы получить данные конфигурации, если кто-то удаляет этот файл. Как указано ранее, машина .Config можно перезаписать, то же самое касается этого подхода. Разрешения каталога могут быть использованы для установки ограничений по чтению и запрещению пишите всем, кроме разработчиков. Это должно сохранить его в безопасности от того, чтобы быть «случайно» переписанным и в то же время гарантируют, что никто не может прочитать данные там (даже если это спорный без ключа)
-121--4349523-TDD наклоняется к мышлениям и экспериментированию с конструкцией класса конкретно с помощью бегового кода, а не абстрактно с карандашом и бумагой.
Оба подхода полезны. Даже Hardcore TDD Zealots используют карандаш и бумагу (или, возможно, доску) иногда, а типы BDUF-UEBER-ALEES будут вытащить случайного прототипа. Вопрос тогда в том, где вы склонны падать: задумчиво или больше практически включения?
TDD о дизайне! Так что TDD вы будете уверены, что ваш дизайн полностью реализован.
Кроме того, «сбалансированный подход» - это путь к ИМО. Вы уже знаете архитектуру высокого уровня, а TDD будет вести эту архитектуру, чтобы быть реализованным.
Редактировать: Хотя, если вы хотите просто практиковать TDD, я бы не сделал «сбалансированный подход». Я бы просто сделал TDD с «детскими ступенями» и, возможно, кодировал Dojos
TDD состоит в том, чтобы позволить тестам привлекать ваш дизайн, включая дизайн вашего класса. Это ценно, потому что тесты предназначены для доказательства того, что код «работает». Это означает, что вы окажетесь от конструкции класса программы, которая работает, в отличие от конструкции класса программы, которая может работать или не работать.
Я думаю, ты упускаешь смысл TDD. TDD не в том, чтобы писать тесты, а в том, чтобы проектировать свои классы так, чтобы они были тестируемыми. Это естественно приводит к лучшему проектированию и реализации.
Звучит так, как будто вы делаете это задом наперёд.
Вашими шагами должны быть:
- Проектирование вашей доменной модели
- Проектирование ваших классов
- Написание некоторых тестов
- Реализация некоторой логики классов
- Рефакторизация ваших классов для того, чтобы сделать их более тестируемыми там, где это необходимо
- Повторение шагов 3-5
Я думаю, что сбалансированный подход - это тот, который вам нужно сделать. Сначала модель классов вашего домена, потому что без них Как вы даже знаете, что тестировать ?
Тогда вы, вероятно, создаете заглушки или оболочки этих классов, с в основном пустыми реализациями, просто Чтобы позволить вам написать некоторые тестовые структуры.
Как только это сделано, ваши тестовые случаи, скорее всего, будут освещать необходимость новых методов / классов / свойств, которые не были в оригинальном дизайне, но были обнаружены как необходимые.
Сбалансированный подход путь.
Тем не менее, баланс обусловлен необходимостью тестирования.
Вы можете сопоставить возможные классы и иерархии. Но вам нужно будет водить дизайн by (1), думая о постижимости и (2) написание тестов перед записью слишком большого количества кода.
Для ваших тестов даже скомпилируйте, вам нужны определения классов. Они не должны работать, но они должны компилировать.
В некоторых случаях ваш класс может быть настолько простым, вы на самом деле пишу все (или почти все) из этого сначала.