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

Question

Я вижу много практикующих TDD, следующих за этим циклом:

1) Напишите свой тест, как если бы цель объекты и API уже существуют.

2) Скомпилируйте решение и посмотрите его перерыв.

3) Напишите достаточно кода, чтобы получить его компиляции.

4) Запустите тест и посмотрите, не удастся ли.

5) Напишите достаточно кода, чтобы получить его проходить.

6) Запустите тест и убедитесь, что он прошел

7) Рефакторинг

В чем преимущество шагов 1 и 2? С IDE, такими как Visual Studio, это действительно раздражает, так как intellisense перепрыгивает повсюду, пытаясь угадать методы и атрибуты, которых там нет.

Обычно я начинаю с шага 3, когда все мои методы выдают исключение NotImplementedException, и мне это кажется вполне подходящим, но, возможно, я что-то упускаю.

Редактировать для уточнения : это не вопрос, почему я должен увидеть, что тест не пройден до того, как он пройдет; это рассматривается на шаге 3, и это имеет смысл. Мой вопрос заключается в том, почему еще до этого люди будут вызывать метод в модульном тесте, который не существует в API (поэтому VS покажет красный загогулин, или раскрасит все имя метода красным и т. Д.) И попытается все равно скомпилировать. Для меня факт, что VS говорит мне, что метод не существует, достаточно хорош.

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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