Привет всем!
Хотелось бы сделать небольшой опрос на тему тестирования веб-приложений. Интересуют следующие вопросы:
1) Какими средствами вы пользуетесь?
2) Довольны ли вы этими средствами и удовлетворяют ли они вашим потребностям?
3) Интегрировал ли кто-нибудь тесты логики приложения с тестами в веб-браузере (JavaScript-тесты). К примеру: в тестовом окружении веб-приложения сделать какой-то setup (БД, кукисы), проверить логику на request/response, провести тут-же JavaScript-тесты в браузере, ajax-запросы и т.д. и сделать teardown.

Надеюсь на ответы, или можно просто коротенько рассказать у кого какое личное отношение к тестам и/или как на работе относятся к тестированию и какие требования предъявляют.

Спасибо!

1. unittest, nose, django.test, twill. Последние, понятно – в веб приложениях. Первые два – и для не-веб тоже.
2. В целом, да. Есть оговорки, но под текущие проекты/задачи – всё ок.
3. Нет.

unittest, nose, mocker плюс buildbot. Без автоматического запуска от тестов толку меньше - просто забивают их проверять.
К тому же хорошо ставить build slaves на отдельных “чистых” машинах - это позволяет выявлять некоторые неявные проблемы конфигурации.
Еще один обязательный инструмент для автоматической проверки - virtualenv. Лучше в варианте without_site_packages. Цель та же - получить “чистую конфигурацию”.

Тестов должно быть больше чем кода - избитая истина.
Сильно помогают не поломать существующий функционал.
Новые ошибки практически не выявляют, что бы там кто не думал - только помогают железно зафиксировать requirements.
Абсолютно бесполезны при создании чего-то совсем нового (или research) - код слишком быстро меняется и тесты за ним не успевают.
К тому же в этой ситуации непонятно, что именно стоит тестировать - а что нет.
Багфикс обязательно должен начинаться с написания ломающего теста до исправления бага. Уберегает от повторного наступления на хорошо знакомые грабли.

На работе тесты приветствуются. Работники их не очень-то любят (с непривычки писать неудобно, субъективно работа движется в три раза медленней, писать тесты без подмены моками и стабами всего, к чему тестируемый метод прикасается - тоже нелегко. Дизайн системы “с тестами” несколько отличается от “дизайна без тестов”). Просветленные - без тестов стараются не делать и шага. Начальство никак процент покрытия кода и качество тестирования не контролирует. Но за баг, который должен был бы быть пойман на юниттесте а вылез только потом, на функциональном или у пользователя - полагается головомойка. Это держит команду в тонусе и в общем все выглядит не так уж плохо.

Андрей, ППКС.

Да, только до continuous integration я так и не добрался, тесты руками. И таки да, бывают эпик фейлы, когда забывают добавить в vcs новый файл ;)

А ты попробуй. Устанавливается и настраивается легко.
По минимуму сказать, чтобы следил за изменениями в vcs, подтягивал исходники и гонял на них юниттесты.

А потом, по мере еды, аппетит прийдет - вместе со сноровкой. И будет билдбот автоматизировать все, до чего можно дотянуться. Чем он мне нравится - легко допилить в случае нужды.

Эээх. Я тут сам себе команда, это все внедрять вроде не для кого :(
Но надо будет попробовать.

Советую пойти по пути j2a - новый баг обязательно начинается с написания теста.
А потом само пойдет.
Несколько лет назад практически тестов не писал, хоть и понимал прекрасно, как оно работает. Того же Кента Бека TDD прочитал, а он очень увлекательно пишет.
Потом пришел на проект, который пишут полсотни программистов. И оценил прелесть идеи - как и ощутил на себе случаи, когда оно не работает.
Тесты - способ поддерживать функциональность в текущем состоянии.
Отсутствие привычной боязни внесения новых изменений - а вдруг что-то сломается?
Лучшее понимание того, как все работает - и как не работает, бросая исключение или возвращая неожиданный результат.
Фиксирование накопленной базы требований к поведению. Если тесты не проходят - то обычно сразу видно, баг это или фича. И правится или код, или тест.
Юниттесты в отличие от функциональных исполняются быстро (на моем проекте в 22 мегабайта питоновского кода меньше 10 минут, в то время как полная QA проверка занимает ночь на пяти машинах).

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

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

Вдогонку статья Брюса Экеля.
Спецификация без тестов бесполезна
P.S.
У него, кстати, есть отличная книга Python 3 Patterns and Idioms. Одна из немногих книг по питону, которую я бы рекомендовал. Разве что еще старенький Dive into Python.

Андрей Светлов
Спасибо, буду разбираться. Надо же когда-то начинать…

j2a спасибо, возможно я тоже обойдусь twill-ом на своих проектах, это немного более честные тесты, чем родные джанговские.
Андрей Светлов спасибо за столь развёрнутый и полезный ответ! Культура написания тестов важна, и чтобы каждый знал зачем это нужно.

Андрей Светлов
полная QA проверка занимает ночь на пяти машинах

А можно про это подробнее? Меня именно такие цифры и пугают:)