Это довольно подробно в вики расписано, но можно тут продублировать.
0. Появляется новыйз use-case (user story). Пользователь зашел на страницу XXX, нажал YYY, увидел ZZZ, при этом в базе был набор AAA, после стал AAAB.
1. Пишется один (!) тест, который все это проделывает. Ес-но все управление на себя наборами данных и прочим стаффом берет фреймворк. В тесте непосредственно два вызова XXX и YYY и последующие ассерты. Формально - это не unit-тест, т.к. покрывает кучу всего.
2. Девелопер убеждается что тест падает 
3. Пишется минимальный код, позволяющий тесту не упасть.
4. Девелопер проверяет что все тесты заработали
5. Рефакторит то, то написал
6. Повторяет.

Если срываться в крайности - то в 0 появляется куча левых стори, типа перебора всех возможных комбинаций входных значений.

На выходе получается софт, в котором (теоретически) все существующие юзкейсы покрыты тестами, т.е. после (5) tdd-ный тест нахаляву превращается в регрессионнный.

А когда есть хотя бы одна старая страница - то регрессия - это заход на нее. Каждая кнопка добавляет в регрессию минимум один юзкейс, и на него тратят время QA.



Именно настолько, и разрыв может быть и побольше. Проблема в том, что написанию тестов обычно мешает не архитектура (что там, заюзать IoC/DI), а именно сам код, который захочется протестировать. А говорить девелоперам "пишите весь код так, чтобы его можно было потом протестировать" - это взывать к их способнастям телепатов  И опять же, тест понадобится тогда, когда он в первый раз упадет. Как ты предлагаешь предугадывать этот момент? 
Проблема как раз в том, что девелопер почти всегда уверен, что он пишет код идеально, и что тесты - бесполезны. Тесты лично девелоперу не нужны, и он искренне удивляется каждому багу. А еще он может сделать любую задачу за 3 дня. ;)

У них абсолютно другая предметная область  Просто тест-oriented архитектура оказалась очень удобна для наколбашивания проектов без тестов.

Дык, делись списком тулзов.

Т. е. тест должен покрывать именно юзкейс? Тогда AFAIK это функциональный тест. Но (!) тогда он (вообще говоря) никак не сможет быстро отработать. Я всё время мыслил о ТДД именно в контексте "быстрых" юнит-тестов и, как следствие, часто запускаемых.


Вот имено, что юзкейсы. Т. е. это исключительно high level тесты. Грубо говоря - код ими не покрывается. Т. е., я не могу гарантировать что этот класс работает правильно. Он работает правильно при том, как он сейчас используется. Нет, это не есть плохо - но это никак не юнит-тесты.

ИМХО, конечно, но функциональными тестами тоже должны заниматься QA. Ибо они не привязаны к внутреннему коду. Если они это автоматизируют, интегрируют в билд-систему и т. д. Отлично. Но девелоперы, я думаю, если и должны писать тесты - то только юнит-тесты.


Я не очень понял. Что значит "мешает код, а не архитектура"?


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


Дык я вначале того.. послушать зашёл  Уникальных тулзов у меня нет. И, самое главное, особо полезного реального экспиринса по внедрению и интеграции - тоже  

Что у вас за юзкейсы такие? O_o? У нас пока в среднем 0.1-0.2с на юзкейс. Вся фишка как раз в том, чтобы заполучить фреймворк, который по настоящему test-friendly, а не "позволяет использовать тесты".
Кстати, в 2010-й студии есть test impact view, который позволяет запускать только затронутые изменениями тесты, если уж дествительно по времени прижимает. 

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

А написание именно unit-тестов вообще на все - действительно бессмысленное занятие. Они слишком дороги в поддержке, повышают стоимость рефакторинга, мешают новому функционалу, и вообще ведут себя не по agile-овски 

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

Проблемы у TDD такие же, как и у Agile:
- его неправильно понимают
- выбирают неверные инструменты
- ударяются в крайности


В том смысле что архитектура - это общее описание того, как работает приложение. А код - непосредственная реализация задумок архитектора. Простой пример - вызов HttpContext.Current сделает кусок кода практически нетестируемым, как бы не продумывал testeability архитектор.


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

При достаточно количестве данных - я не представляю, как это может быть 01.-0.2 секунды :(


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

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

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

Ну.. не всякой страницы. Есть фичи, которые в любом случае занимают время - и это нормально. Но это один (!) тест. А если тестировать весь проект - это явно приличная задержка.. Что-то я всё-таки не понимаю 

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

Не, с CI всё понятно. Непонятно с TDD. Ибо в моём понимании ТДД предполагает частый запуск тестов девелопером. А тесты после билда - в этом ничего нового нет (всё равно, конечно, далеко не всегда эти тесты автоматизированны, но я не отношу это к ТДД).

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

Можно понаблюдать за собой, как типичный разработчик пишет код в среднем таком проекте
1. рисует зародыш ui
2. пишет логику
3. дергает ее из ui
4. правит баги
5. повторяет раз так N
6. коммитает

Минусы: 
- занимается ручным тестированием, что при некотором количестве итераций (то 2-х) просто медленнее, чем один раз написать тест
- он не оставляет артефактов в виде теста, т.е. работа по ручному тестированию не приносит пользы в будущем

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

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

Ой нафлудили  На выходных отдызать нужно   


Я отнес ее ко второй части абзаца.  

Это его проблема. А не Agile. 

Врядли, скорее всего умею  И чтобы не было недопониманий: я не против тестов, я против TDD (в чистом виде и на 100%-х функциональности).

Ты про TDD или про тесты вообще?


+1 Кроме того: почти все в нашем мире нужно адаптировать под себя (что хорошо одному -- другому смерть Ж)) )


А зачем полностью? Это не точная наука. "Внтуреннего голоса" вполне достаточно. Ведь любую ошибку можно исправить.


Гнилая отмазка. Уж не обижайся.


Ну ты уже понял, Паша, что я с тобой тут не согласен   

  

Паш, у тебя неправильное ТДД. Причем я даже не знаю как тебя переубедить. У тебя скорее FTDD (Functional TDD). И я совсем не представляю как твое TDD может помочь в дизайне приложения.

СУВ, Aikin

Это сообщение отредактировал(а) ivashkanet - 9.11.2009, 10:30

И про то и про другое. Вообще любое тестирование должно поддерживаться всей командой.

В чем именно не согласен? Ты пробовал именно Unit-тесты, перед разработкой? Как unit-тесты могут помочь в дизайне всего приложения, а не отдельных юнитов? Чтобы написать тест на юнит, нужно сначала принять решение о существовании этого юнита, а это решение - и есть построение дизайна. А когда юнит появился - то никакой тест на него не может дизайн изменить.

А FTDD (скорее уж, tests before development) очень классно помогает. Именно тем, что оно определяет дизайн всего приложения, а не тестирует юниты уже в готовом дизайне.
  
Я вообще-то выше написал что у нас не TDD  в чистом виде. Но зато у нас тесты есть, практически на весь функционал, и вся команда понимает их необходимость. А у вас - нет ;)

Переубеждай ;)

Это с точки зрения разработчика - программирование - это исскуство, с неточными числами и загадками.
Внутренний голос разработчика говорит "да подумаешь, это можно исправить, не проблема, работы то тут на 5 минут".
Внутренний голос QA - "опять исправять что-то внутрях, мне из-за этих 5-ти минут все перетещивать. В прошлый раз поверил что функционал YYY не затронет - а там все поломалось. Когда эти криворукие девелоперы научатся код без багов писать"

А вот у манагера все просто. С его точки зрения стоимость ошибки - вполне точная сумма в $. Можно даже прайс нарисовать.
- баг повалил тесты при билде - 5$
- из-за бага билд у QA не запустился вообще - 50$
- баг нашли QA во время smoke - 500$ за все баги
- баг найденный QA во время регресии - 1000$ за все баги
Прайс нашептан моим внутренним голосом, но легко вычисляется из количества людей, через которых проходит билд, их зп, и среднего времени обнаружения первых багов.

Если учесть что TDD -- подмножество тестов, то про тесты вообще. Так вот. Все что я говорил выше к тестам вообще не относится. Только к TDD.


Мы уже как-то нафлудили несколько страниц. Неохото повторяться.


А потом, через несколько лет успешных и не очень проектов, манагеру открывается ДАО: для проекта дешевле поощрять инициативу программистов и дать им возможность совершать ошибки. Вот только прайс под это дао уже не подведешь.

Добавлено через 3 минуты и 35 секунд

Ну кто сказал, что у нас нет тестов практически на весь важный функционал (60-70% покрытия)? Я такое не говорил.

Какое отношение возможность совершить ошибку имеет к инициативе? Повышать инициативу (мотивировать) можно кучей разный способов, но "разрешить не писать тесты" среди них точно нет.
По личному опыту - на долгоиграющем проекте ДАО открывается как раз в обратную сторону :(
 А еще чуть позже приходит просветление что нужны именно функциональные тесты, т.к. за пару лет архитектуру переколбашивает, и unit-тесты становяться все дороже в поддержке.

ivashkanet, ты манагер или девелопер? судя по подходу - девелопер 



Т.е. вы не уверены в 60-70% своего кода? 

В чём проблема?   Не вижу гнили 
Осталось только скан NDA предоставить