TDD в JavaScript. Разработка приложения

[mark_ablov]

> Итог говорит в пользу TDD — в первом модуле QA нашли лишь небольшие проблемы с графикой в IE9, зато во втором — неприятный баг

Итог: 1 баг при TDD и 1 баг при обычной разработке, при этом времени затрачено было на 40% ,jkmit/
Что-то не так? :)

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

Я предпочитаю сначала написать код, а потом накладывать на него юнит-тесты, дабы следующие версии ничего не ломали. А не наоборот.
Хотя наверно, это дело вкуса.

[ArtyomTrityak]

Баг в ИЕ9 был скорее не багом — на 10 пикселей ниже чем нужны было завершение окна. И даже если бы QA не нашли — приложение работало бы корректно, скорее всего пользователи не узнали бы о том, что баг существует. Ну разве что сравнили с другим браузером.

Я же писал — проектирование при помощи TDD. Все дело привычки и личных предпочтений — на практике для моего проекта методология TDD показала потрясающие результаты.

[alprk]

Все-таки, тесты проще писать сразу, просто нужно привыкнуть.

[evilbloodydemon]

писать тесты после — все равно что не писать вовсе

[kuber]

> «Использование методологии TDD увеличивает время разработки приблизительно на 40%, но сокращает время багфиксинга в разы.»

Откуда эти цифры?

[TheShock]

87,6% всей статистики берется методом Стели

[ArtyomTrityak]

Реальный опыт разработки

[savados]

У вас больше половины тестов проверяют, что есть такой-то объект, и у него есть методы с такими-то названиями. Это реально так полезно и спасает от кучи багов потом?

[savados]

Да, и правильнее будет «check existence of».

[s1im]

Тесты в основном пишутся не для того, чтобы проверить «сейчас», а для того чтобы ничего не сломать «потом».

[VolCh]

Для динамических интерпретируемых языков полезно, если хочется получить внятное сообщение о том, что метода не существует, а не эксепшен в тесте на то что метод возвращает.

[ArtyomTrityak]

Эта часть тестов является проектированием через тестирование.
Код непосредственного тестирования результатов находится после проектирования. Ведь логично сперва разработать структуру, а лишь затем — реализацию. Об этом я как раз и писал.

По поводу полезности от куч багов — дальнейшие проверки проверяют как раз корректность выполнения методов.

Я не стал перегружать излишними проверками, т.к. лишь показал общий принцип. В реальном объекте тесты проектирования занимают менее 10%

[VolCh]

Было бы интересно прочитать про инструментарий и вообще организацию тестирования клиентского JavaScript. На сервер-сайде применяю давно, а вот как тестировать на клиенте то, что сервер выдал не очень представляю. Посмотрел QUnit, но всё равно как-то не понял как тестировать. Вот есть страница, есть JS, который работает с её DOM в том числе через AJAX. Куда тесты вставлять, как проверять что функция корректно DOM изменила?

[VolCh]

P.S. Картинку сами рисовали? Как-то странно выглядит — как минимум нет тестов после того как почистили код.

[ArtyomTrityak]

Картинка взята с википедии. При дальнейшей разработке мы выполняем все тесты и в любом случае видим, если что-то сломалось.

[VolCh]

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

[ArtyomTrityak]

Это очень интересная (лично для меня) тема и она достойна отдельной статьи. Как только я найду чуть больше времени я обязательно напишу про асинхронное Ajax тестирвоание

[VolCh]

Буду ждать. Заранее спасибо.

[plagi]

Советую так же посмотреть на Jasmine фреймврок. Тоже достаточно удобно.

[ArtyomTrityak]

Спасибо, посмотрю

[ArtyV]

С qunit не сравнить, он в разы круче

[ArtyV]

*jasmine круче

[plagi]

Я сначала не понял, про что вы, хотел уже написать комментарий в защиту :)

[ArtyV]

Да я и сам не понял ага :D

[ilyakharlamov]

У qUnit, на мой взгляд, есть недостаток — он требует ручного запуска/перезапуска браузера, что надоедает. Чтобы не обращаться к браузеру и получить TEST PASSED/TEST FAILED из коммандной строки или автоматического сервера интеграции типа Hudson, то рекомендую jstestdriver

[phgrey]

Лично мне статья пмогла понять что же такое TDD вообще. Спасибо.
>Если будут желающие, то могу продолжить про TDD и Ajax, тестирование сложных модулей, асинхронное тестирование >состояний, автоматически генерируемые мок-объекты и фреймверки для этого.

Есть, есть желающие!