Вы не смешивайте TDD и UnitTests - это принципиально разные вещи, только инструменты одинаковые.

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

Добавлено через 5 минут и 17 секунд

Нет, не так: познакомившись с TDD... знаком с юнит тестированием  

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

Юнит-тестирование (Test-before-development) - это когда перед написанием какого-то конкретного куска пишется тест для него.

Разница в результате - При TDD получаются автоматические regression-тесты для приложения. При Unit-тестировании получаются отдельные тесты для каждого юнита, и для каждого уровня - свой набор тестов для UI, набор для BL, набор для DA.

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

Это я как бы к тому, что знакомство с TDD не дает навыка написания unit-тестов.

Это сообщение отредактировал(а) PashaPash - 9.7.2009, 19:19

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


Первый раз о такой практике слышу   
Т.е. TTD -- пишем интеграционные тесты на все юзкейсы, а потом заставляем их пройти? Жесть. Паш, ты извини, но, ИМХО, ты не совсем в курсе что такое TDD:
 
Но это русский вариант, у нас, обычно, в вики пишут что в голову взбредет (сама фраза "модульные тесты для программы или её фрагмента" это нечто   ).

В английской википедии в определении нигде нет "Юнит Теста", есть только "тест перед кодом":

И я с этим согласен, тест перед кодом -- ключевой аспект TDD. В определение ничего дополнительно добавлять не нужно. Даже Red-Green-Refactor -- ключевую фичу TDD не обязательно затрагивать. Но если посмотреть на примеры Бекка (или другой книги по TDD) окажется, что эти тесты -- юнит тесты. Так как в TDD требуют двигаться маленькими шажками: один цикл (R-G-R) занимет, в теории, не более 5 мин.  В случае интеграционных тестов это невозможно.
Когда говорят о TDD в 90% случаях имеют ввиду именно Юнит тесты. Да и вообще, очень тяжело не программисту написать тесты ДО кода. А тесты программиста -- именно юнит тесты (интеграционными и проч, занимаются QA).
Лично я TDD-чу именно юнит тестами.


Возможно ты говоришь про ATDD (если честно, первый раз такое услышал):

Оказывается тоже есть такая практика, но она не столь широко распространена. Я услышал о ней впервые, хотя в "Test-Driven Development in Microsoft .NET" рассказывается про FIT приемочное тестирование (тогда я не придал значение тому почему FIT рассматривается в книге по TDD).

СУВ, ivashkanet

Ес-но тесты пишутся по одному, и т.д  Я хотел показать что TDD-тесты не тестируют отдельные юниты (классы, методы), а проверяют тесткейсы. Один тесткейс вполне может покрывать 20-30% кода приложения - слишком много для "теста одного юнита". 


Зато в английской википедии есть определение Unit testing, где про "перед кодом" в определении ничего не сказано. Зато там есть "tests that individual units of source code" и "A unit is the smallest testable part of an application."


Немного не согласен с этим утверждением - и с выводами из него. TDD - это процесс разработки. Из 6 пунктов. Если ты оставишь "основной аспект" и выбросишь остальные - то получишь обычный Tests Before Development. 

Есть неплохая статья на эту тему: http://stephenwalther.com/blog/archive/200...unit-tests.aspx, ну и та же рядом: http://stephenwalther.com/blog/archive/200...evelopment.aspx

З.Ы. Впрочем, whom how. IMHO - просто писать тесты до кода - намного лучше, чем вообще их не писать. И не обязательно хуже TDD.


Это сообщение отредактировал(а) PashaPash - 10.7.2009, 13:27

Не мог ты подкрепить свое мнение ссылками на источники?


Who is Stephen Walther??? Очередной толкователь создателей TDD? Они оказывается имели ввиду не то что написали, а вот это и вот это... А пацаны-то не знают 


Из 5-ти (если судить по книге Бекка). Что есть "обычный Tests Before Development". Что это вообще за термин? Кто его ввел? Кто о нем знает? Почему Гугл не знает?


Так вот, из "пяти пунктов TDD" убрать можно только Рефакторинг и стадия Red (запускаем тест до написания кода и убеждаемся что он валится). Все остальные (добавить тест, добавить код для прохода теста, запустить тесты) естественны для TBD (Test-before-development). 
Идем далее. Стадия Red естественна для TBD. Так как если только что написанный тест прходит, то этот тест ничего нового не тестит. Нафик он нужен.

Получается, что TDD отличается от TBD только стадией рефакторинга (ну и принципом "пишем минимальный код который проходит тест", но он опирается на стадию рефакторинга).


P.S. PashaPash, ты мне лучше скажи, неужели в TBD обязательно должны быть юнит тесты. С тем же успехом я могу сказать, что к TBD относятся и приемочные, и интеграционные тесты.


Не понял что ты этим доказываешь. Что такое Юнит тест я знаю. Он никак не завязан на TDD. Наоборот TDD завязан на на тесты (чаще всего на Юнит тесты). 
Это ты почему-то решил, что Юнит тест == TBD:

Дык, википедия же

А как же repeat? 

Да так, гугл нашел. MVP какой-то. Все усиленно толкуют TDD, и каждый по своему. Выбросим из TDD пару пунктов - да не проблема, TDD хуже не станет. Зачем писать минимальный код - будем писать сразу фреймворк, это ж не последний тест. Зачем рефакторить (и когда именно рефакторить)? Только чтобы убрать дублирующйся код? В какой момент проявлять знание ОО-паттернов? Только при рефакторинге? Писать юнит-тесты, или все-таки не-юнит? Вот, уже на целую книгу толкований. 
Это "небольшое" отличие подразумевает некоторый отказ от планирования "на будущее" - потому что надо писать именно "минимальный код". Не надо толковать идеи пацанов по-своему (С) 


Потому что в моем определении есть слово "конкретного куска", он же модуль, он же юнит.

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

Вобщем, предлагаю завязать с холивором, не вижу смысла особо продолжать, или выносить в отдельную тему. Один вопрос для ясности.

Я бы заменил на "чаще всего не unit-тесты". Что является юнитом в типичном TDD тесте для приложения? Пример - 3-layer web-приложение, пишем тест для тесткейса "при нажатии на кнопку create user, в базе (репозитирии) создается новый user, пользователя редиректит туда-то". Что здесь юнит? метод в UI-логике? Класс в BL?

Сам хотел предложить   Очень неблагодарное это дело... все равно каждый останется при своем   

P.S. 
В TDD главное, что "тесты уравляют разработкой".

Добавлено через 1 минуту и 27 секунд

ИМХО, лучше вынести. Пусть останется для потомков Ж))