Comments 26
> Итог говорит в пользу TDD — в первом модуле QA нашли лишь небольшие проблемы с графикой в IE9, зато во втором — неприятный баг
Итог: 1 баг при TDD и 1 баг при обычной разработке, при этом времени затрачено было на 40% ,jkmit/
Что-то не так? :)
Проектирование != TDD, проектирование можно делать в удобных средах, и даже на бумажке, строя вменяемую архитектуру, без всякого TDD.
Я предпочитаю сначала написать код, а потом накладывать на него юнит-тесты, дабы следующие версии ничего не ломали. А не наоборот.
Хотя наверно, это дело вкуса.
Итог: 1 баг при TDD и 1 баг при обычной разработке, при этом времени затрачено было на 40% ,jkmit/
Что-то не так? :)
Проектирование != TDD, проектирование можно делать в удобных средах, и даже на бумажке, строя вменяемую архитектуру, без всякого TDD.
Я предпочитаю сначала написать код, а потом накладывать на него юнит-тесты, дабы следующие версии ничего не ломали. А не наоборот.
Хотя наверно, это дело вкуса.
Баг в ИЕ9 был скорее не багом — на 10 пикселей ниже чем нужны было завершение окна. И даже если бы QA не нашли — приложение работало бы корректно, скорее всего пользователи не узнали бы о том, что баг существует. Ну разве что сравнили с другим браузером.
Я же писал — проектирование при помощи TDD. Все дело привычки и личных предпочтений — на практике для моего проекта методология TDD показала потрясающие результаты.
Я же писал — проектирование при помощи TDD. Все дело привычки и личных предпочтений — на практике для моего проекта методология TDD показала потрясающие результаты.
Все-таки, тесты проще писать сразу, просто нужно привыкнуть.
писать тесты после — все равно что не писать вовсе
> «Использование методологии TDD увеличивает время разработки приблизительно на 40%, но сокращает время багфиксинга в разы.»
Откуда эти цифры?
Откуда эти цифры?
87,6% всей статистики берется методом Стели
Реальный опыт разработки
У вас больше половины тестов проверяют, что есть такой-то объект, и у него есть методы с такими-то названиями. Это реально так полезно и спасает от кучи багов потом?
Да, и правильнее будет «check existence of».
Тесты в основном пишутся не для того, чтобы проверить «сейчас», а для того чтобы ничего не сломать «потом».
Для динамических интерпретируемых языков полезно, если хочется получить внятное сообщение о том, что метода не существует, а не эксепшен в тесте на то что метод возвращает.
Эта часть тестов является проектированием через тестирование.
Код непосредственного тестирования результатов находится после проектирования. Ведь логично сперва разработать структуру, а лишь затем — реализацию. Об этом я как раз и писал.
По поводу полезности от куч багов — дальнейшие проверки проверяют как раз корректность выполнения методов.
Я не стал перегружать излишними проверками, т.к. лишь показал общий принцип. В реальном объекте тесты проектирования занимают менее 10%
Код непосредственного тестирования результатов находится после проектирования. Ведь логично сперва разработать структуру, а лишь затем — реализацию. Об этом я как раз и писал.
По поводу полезности от куч багов — дальнейшие проверки проверяют как раз корректность выполнения методов.
Я не стал перегружать излишними проверками, т.к. лишь показал общий принцип. В реальном объекте тесты проектирования занимают менее 10%
Было бы интересно прочитать про инструментарий и вообще организацию тестирования клиентского JavaScript. На сервер-сайде применяю давно, а вот как тестировать на клиенте то, что сервер выдал не очень представляю. Посмотрел QUnit, но всё равно как-то не понял как тестировать. Вот есть страница, есть JS, который работает с её DOM в том числе через AJAX. Куда тесты вставлять, как проверять что функция корректно DOM изменила?
Советую так же посмотреть на Jasmine фреймврок. Тоже достаточно удобно.
У qUnit, на мой взгляд, есть недостаток — он требует ручного запуска/перезапуска браузера, что надоедает. Чтобы не обращаться к браузеру и получить TEST PASSED/TEST FAILED из коммандной строки или автоматического сервера интеграции типа Hudson, то рекомендую jstestdriver
Лично мне статья пмогла понять что же такое TDD вообще. Спасибо.
>Если будут желающие, то могу продолжить про TDD и Ajax, тестирование сложных модулей, асинхронное тестирование >состояний, автоматически генерируемые мок-объекты и фреймверки для этого.
Есть, есть желающие!
>Если будут желающие, то могу продолжить про TDD и Ajax, тестирование сложных модулей, асинхронное тестирование >состояний, автоматически генерируемые мок-объекты и фреймверки для этого.
Есть, есть желающие!
Sign up to leave a comment.
TDD в JavaScript. Разработка приложения