Как стать автором
Обновить

Комментарии 23

Ну наконец то на Хабре опубликовали полезный пост.
Спасибо.
спасибо за статью. в закладки одноззначно
а где можно почитать побольше про юнит тесты? у меня возникла проблема с ними — на этапе разработки слишком много времени уходит на написание фикстур и т.д. Как правильно пользовать юнит тесты в условиях быстро меняющихся условий?
JS Ninja — как раз ничанается с концепции юниттестов.
а скажите кто-нибудь внятно — она уже вышла? :)
хороший вопрос.
в процессе работы над очередной версией компонента/проекта имеет смысл писать тесты на неизменяемый функционал — отправка письма, доступ к данным и сервисам.
бизнес-логику, которая сильно подвержена изменениям лучше покрывать тестами выборочно и ближе к концу текущей версии.
если бизнес-логика сильно меняется от версии к версии, то тут надо решить что важнее — время разработки или стабильность релизов, хотя чаще всего можно найти компромис.
А есть ли смысл тратить время, покрывая юнит тестами мелкий функционал, особенно отправку писем. Это достаточно просто проверяется и врядли сломается. А вот как раз бизнес логика, где полно связаных компонентов, вот тут и возникают проблемы, с тем, что после изменений система работает, но с ошибкой. Из моего опыта чаще всего появляются баги:
1) верстка — тут уж только визуально, заодно и тестирование функционала
2)SQl скрипты — из за ошибки в скрипте берутся либо не те данные, либо не в правильном порядке, либо сохраняются нетуда, ХЗ как такое проверить и протестировать
3) Логика — чаще всего в операторах IF и switch. тут как раз, как я понимаю, и помогут юнит тесты.
4) плохие входные данные — тут опять же помогут юнит тесты.
> 2)SQl скрипты — из за ошибки в скрипте берутся либо не те данные, либо не в правильном порядке, либо сохраняются нетуда, ХЗ как такое проверить и протестировать

А в чем проблема? При запуске тестов создается временная база данных, заполняется тестовыми данными и проверяется работоспособность. По окончании база грохается.
я говорил не про мелкий функционал, а про неизменяемый. отправка письма в интернет-магазине является критичным функционалом и может отваливаться когда захочет.
про верстку говорить не буду — с ней все понятно.
про доступ к данным я упомянул — я создаю тестовую БД и на ней тестирую.
логику — ближе к концу итерации. только логика — это не if и switch ;)
валидация — само собой.
Кстати по поводу правильного использования. Один из методов — разработка через тестирование. По ссылке все достаточно коротко и понятно написано.
Да, согласен с Вами, писать тесты до самого функциональности — хорошая практика. К сожалению, не всегда получается применить в жизни.
Могу даже уточнить — практически никогда не получается. Сам применяю только когда пишу для себя — медленно, аккуратно и без меняющегося непрерывно ТЗ. Зато как потом работает и удобство по добавлению новых функций/исправлению багов выше всяких похвал.

Но даже когда не получается этот метод использовать хорошо о нем помнить. Всегда можно написать таким методом не весь код, а только «ядро» или потенциально проблемные участки.
Нужно стремиться «покрыть» код тестами как можно полнее. Такое покрытие дает большой плюс при развитии уже внедренного продукта. Например, создали мы библиотеку, внедрили ее в свой проект, раздали в бесплатное пользование=). Все заработало, люди пользуются. Со временем оптимизируем ее и запускаем тесты на оптимизированной библиотеке. Если тесты прошли — значит новую версию с большой долей уверенности можно внедрять. Если нет — высока вероятность, что расти будет багтрак.
Отличный топик! Я сам хотел написать про qunit, но вы меня опередили :)
Всегда можно написать лучше ;)
Читаю комменты и понимаю, что многие темы не раскрыты, например тестирование до разработки, либо тестирование в рабочем окружении.
А мне больше jspec нравится (не путать с jsspec): github.com/visionmedia/jspec

Умеет все то же самое (а, вероятно, и больше, на qunit детально не смотрел: как там у него с загрузкой html-фикстур, иерархией тестов с общими подготовительными действиями?), + очень приятный синтаксис.

Если кого смутит, что там как будто тесты не на js нужно писать — это не так, там можно и на js писать, просто для сокращения количества писанины там препроцессор сделан.

Еще есть jsTestDriver ( code.google.com/p/js-test-driver/ ), штука позволяет запускать js-юнит-тесты (втч написанные на qunit) сразу в нескольких браузерах автоматом — из командной строки или по нажатии кнопки в плагине к эклипсу, и передавать результаты в браузер, в командную строку или эклипсовскому плагину. Причем запускать тесты можно даже на браузерах, которые расположены на другом компьютере. Это удобнее, чем в браузере смотреть, и еще более все автоматизируется. + Удивительно простая установка и настройка, все сразу работает. Только 1 минус — с mootools & prototype не работает ну никак, поэтому не использую)
Спасибо за ссылки. Надо попробовать.
jspec 404 теперь выдаёт (
Также используем QUnit. У него есть странная, но похоже фундаментальная проблема — поскольку тесты запускаются в отдельном окружении, то часто глючат связи с плагинами. Чаще всего у нас проблемы с jQuery.Cookie — плагин не инициализируется в тестовом окружении. «Голые» же тесты — на ура, простенько и аккуратно.
При всём моём уважении к jQuery, JSpec мне нравится больше, хотя бы более красивой страницей вывода результатов :).
Вот тут в конце поста дан альтернативный вариант запуска теста асинхронной цепочки вызовов.

Для знакомства весьма подробно.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории