В TDD, каково преимущество запущения тестов прежде даже записать пустой метод?

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

Это связано с этот ответ на другой вопрос , используйте голову сначала! Это - лучшая лучшая практика.

Что касается меня "посмотрите красную загогулину" == отказавший компилятор. Помните, что исходный модульный тест / манифесты TDD был записан без IDE в памяти. Хорошие IDE были очень редки в мире Java тогда, и как другие отметили, динамические языки все еще не могут решить, что метод не существует во время компиляции, период.

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

Я думаю, что использование инструмента как Resharper поможет Вам получить лучшее ощущение TDD. Это, конечно, сделало для меня.

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

Это не Разработка через тестирование книгой . "чиновник" процесс TDD , как описано в Beck' "Разработка через тестирование: примером" следующие:

• Быстро добавляют тест
• Запущенный все тесты и видят новый один , сбой
• делает мало изменение
• Запущенный тесты и видит их , все успешно выполняются
• , Осуществляют рефакторинг для удаления дублирования

Опасность здесь состоит в том, что Вы предполагаете свой API при записи первого теста. Один прием должен думать о первом тесте - возможно, пишут его на бумаге или, по крайней мере, вне VS - прежде чем Вы начнете писать код. Как только Вы знаете методы, API будете нужны Вы, может возобновить шаг 3 и затем отследить в обратном порядке (относительно VS) к шагу 1 и записать фактический тест.

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

Помните, во-первых, что основной цикл является red-green-refactor. Также - сбой кода для компиляции не является частью базового цикла TDD вообще. Однако как несколько человек указали, полезно считать API с точки зрения теста созданным, и это - то, где Ваши первые два шага имеют тенденцию добиваться признания. Если Вы пишете API путем, Вы хотите, чтобы он работал для создания теста простым, Вы, намного более вероятно, будете счастливым потребителем класса под тестом.

Относительно поддержки Visual Studio TDD, я соглашаюсь, что intellisense будет иногда мешать, но можно на самом деле использовать VS для TDD, хотя это все еще несколько ограничено. Если метод тестирования обращается к несуществующему методу на классе под тестом, у Вас может быть VS, создают тупик для Вас путем нажатия Ctrl-K, Ctrl-M.

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

Я вижу, что у многих людей ответить на этот вопрос есть фон Visual Studio. Я использовал VS сам и боролся с теми же проблемами, на которые Вы указываете с первыми двумя шагами TDD.

при использовании более мощного кода, редактируя IDE, как то, что Вы имеете в Java (Eclipse, Netbeans, IntelliJ), первые два шага имеют больше смысла. Быстрые исправления и средства генерации кода, доступные там, делает запись теста против несуществующего класса или метода самым быстрым способом создать тот конкретный класс или объявить что конкретный метод; можно просто нажать кнопку, и недостающий класс или метод сгенерированы для Вас. Запись вызова метода или объектного инстанцирования более быстра что, создавая класс или метод сначала, затем с помощью них. Как только Вы назвали метод, например, он дан именем метода и типами параметра, какова подпись метода должна быть, таким образом, для IDE легко создать их. Это - действительно замечательный процесс, и я не программировал бы никакой другой путь. Объедините это с преимуществами фактического работания с API, прежде чем это будет существовать, Ваш описанный способ выполнить TDD имеет много смысла.

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

Для пользователей Visual Studio, если Вы хотите обменяться этим опытом, устанавливают плагин Resharper для Visual Studio. Это даст многие из тех же функций, которые доступны в IDE Java.

запись тестов сначала вынуждает Вас выбрать интерфейсы

, который является всем.

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

РЕДАКТИРОВАНИЕ: я действительно должен считать вопрос более тщательно, OP искал более определенный ответ. Вот это: опустите шаг 2 в Visual Studio, заблокируйте методы/классы вместо этого. Нет никакой причины быть педантичным о следующем этот расширенный рецепт, когда это ясно не необходимо с инструментами, каждый использует.

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

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

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

РЕДАКТИРОВАНИЕ: От Justin Standard...

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

РЕДАКТИРОВАНИЕ: От senfo...

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

@senfo: Слишком много сложности в иерархии наследования может, конечно, произойти, но это - различная проблема с очевидным решением. Даже если Ваш существующий код прекрасен, все еще ценно запуститься с модульного теста, который пытается вызвать возможно несуществующий метод, только быстро доказать себе, что это не существует. Конечно, пропуск того шага понятен - я мог бы возвратиться к нему в определенной ситуации, где мой тест неправильно себя ведет (для проверки в той конкретной ситуации, что я не вызываю что-то другое, чем, что я просто записал).

Рабочий процесс в Eclipse с JUnit (в противоположность Visual Studio с MSTest) - то, где шаги 1-3 имеют большую часть смысла. Шаг 3 тогда просто использует функциональность Быстрого исправления Eclipse (Ctrl-1) для генерации тупикового кода на основе модульного теста, который Вы просто записали.

DoesntExistYet someObject = новый DoesntExistYet ();
интервал заканчиваются = someObject.newMethod ("123");
assertEquals (123, результат);

Быстрое исправление для первой строки автоматически создаст класс DoesntExistYet (разрешение Вам пройти мастер сначала для тонкой настройки его), и следующее быстрое исправление создаст newMethod для Вас, соответственно выясняя подпись на основе того, как Вы использовали его.

Так со все, что automagicification создание легче вещей, Вы тогда углубляете другим людям преимуществ, упомянуло о способности спецификации Ваш API тем, как Вы использовали бы его.

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

Попытка это как пересмотренная последовательность:

1) Запись Ваш тест в рамках комментария , как будто целевые объекты и API уже существуют.

2) Запись как раз достаточно кода API для компиляции.

3) Некомментарий Ваш тестовый код.

4) Запущенный тест и посмотрите, что он перестал работать.

5) Запись как раз достаточно кода, чтобы заставить его передавать.

6) Запущенный тест и посмотрите, что он передает

7) Промывка и повторение...

Тот путь Вы все еще извлекаете пользу из взгляды тест сначала, а не реализация сначала.

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

кроме того, пытаясь "использовать" API заставляет Вас думать об этом от другой точки зрения (тот из пользователя API ), который почти всегда выгоден. Важно сделать это прежде , Вы пытаетесь записать API (который всегда будет с точки зрения разработчика API ). Трудно объяснить значение использования Ваших собственных API, но промышленное понятие собака-fooding .