Комментарии 13
в вашу копилку: Selenium без тормозов
Докладчик: Алексей Баранцев
Докладчик: Алексей Баранцев
Отключаем native events — и половина обработчиков JQuery перестаёт срабатывать, ага.
Ускорять ввод текста, если это самое узкое место лучше другим способом: вводить текст «куском» — запихнули в клипборд, поставили фокус на поле ввода, послали Ctrl-C, и всё мигом вставилось.
Ускорять ввод текста, если это самое узкое место лучше другим способом: вводить текст «куском» — запихнули в клипборд, поставили фокус на поле ввода, послали Ctrl-C, и всё мигом вставилось.
Тьфу! Crrl-V, конечно :)
Не понимаю, как скорость ввода может влиять на обработчики jQuery.
Если пользоваться буфером обмена, то запуск нескольких броузеров одновременно на одном компе может привести к конфликтам, т.е. надо синхронизировать буфер, чтобы одновременно пара тестов в него не запихнули чего-нибудь своё.
Если пользоваться буфером обмена, то запуск нескольких броузеров одновременно на одном компе может привести к конфликтам, т.е. надо синхронизировать буфер, чтобы одновременно пара тестов в него не запихнули чего-нибудь своё.
Если отключить использование нативных ивентов — будет, грубо говоря, только onChange в конце. Если вставлять через клипборд — примерно то же самое. И по скорости, и по набору событий.
При использовании нативных ивентов на каждый вводимый символ генерируется полный набор событий — keyDown, keyPress, keyUp. Отключив их, вы полностью лишите себя возможности тестировать корректность работы, скажем, автопродолжения или валидации в процессе ввода.
Про несколько браузеров согласен. Виртуалки рулят (с отключенной интеграцией клипборда, естественно).
При использовании нативных ивентов на каждый вводимый символ генерируется полный набор событий — keyDown, keyPress, keyUp. Отключив их, вы полностью лишите себя возможности тестировать корректность работы, скажем, автопродолжения или валидации в процессе ввода.
Про несколько браузеров согласен. Виртуалки рулят (с отключенной интеграцией клипборда, естественно).
Для проверки работы валидации (и вообще для тестирования JavaScript) мы используем QUnit-тесты. Они гораздо быстрее и, следовательно, экономичнее.
Если эти штуки тестировать не надо — тогда в Selenium можно вообще врубить HtmlUnitDriver, и не будет ни браузера, ни нативных ивентов, но зато будет очень быстро.
ммм, интересная логика. Как я понимаю, Вы с помощью Selenium предлагаете тестировать всё на свете и не писать юнит-тестов на JavaScript, а уж если писать юнит-тесты, то Selenium как-то и не нужен.
На самом деле всё гораздо проще
1. С помощью QUnit мы тестируем код JS, включая и валидацию. Я думаю, Вы понимаете, что для тестирования валидации вводимых пользователем данных, совсем не обязательно запускать веб-сервер, деплоить приложение и плодить selenium-тесты.
2. С помощью Selenium мы тестируем работу системы в целом, а не отдельного компонента. Если отказаться от Selenium'а, то очень велика вероятность, когда все юнит-тесты проходят, а приложение не работает.
На самом деле всё гораздо проще
1. С помощью QUnit мы тестируем код JS, включая и валидацию. Я думаю, Вы понимаете, что для тестирования валидации вводимых пользователем данных, совсем не обязательно запускать веб-сервер, деплоить приложение и плодить selenium-тесты.
2. С помощью Selenium мы тестируем работу системы в целом, а не отдельного компонента. Если отказаться от Selenium'а, то очень велика вероятность, когда все юнит-тесты проходят, а приложение не работает.
Как раз и предлагаю — сначала на QUnit делаем модульные тесты, а потом используем в Selenium движок HtmlUnitDriver, который имеет ограниченные возможности по поддержке AJAX, но зато быстрый, и проверяем логику интегрально.
Мысль интересная, но уж очень сложно реализуемая. Как ни крути, но у QUnit есть недостаток: ему нужна тестовая html-страничка, которая часто представляет собой кусок продакшн страницы. Таким образом, запуская интегральный тест на qunit, мы всё же запускаем его на тестовой странице, а не на продакшн. Можно конечно извернуться и в продакшн страницу вставлять javascript для запуска qunit-тестов, но стоит ли игра свеч?!
Ну и к тому же, все подобные тесты закончатся на первом же сабмите формы.
Ну и к тому же, все подобные тесты закончатся на первом же сабмите формы.
Заходим селениумом на нужную страницу, подкачиваем из внешнего файла JS-тесты для этой страницы, селениумом заливаем их в браузер, дёргаем пускач, тесты добегают — а дальше селениум проверяет всё остальное. На следующей страничке повторяем. Естественно, делаем опцию, чтобы можно было отключать модульные тесты, когда надо прогнать только интеграционные.
А если keyUp/keyDown/keyPress обрабатываются при вводе текста, да ещё и event с буфером на 200 милисекунд?
Из моей практики примерно 1/5 ошибок — проблемы рассинхронизации анимации, или потери цепочек в асинхронных событиях. При таких ускорениях они в принципе не ловятся тестами. Проще поднять какой-нибудь грид тестов, чем так — имхо. А за статью спасибо :)
Из моей практики примерно 1/5 ошибок — проблемы рассинхронизации анимации, или потери цепочек в асинхронных событиях. При таких ускорениях они в принципе не ловятся тестами. Проще поднять какой-нибудь грид тестов, чем так — имхо. А за статью спасибо :)
а если вы используете capybara для тестирования, просто используете capybara-webkit вместо selenium. Прирост скорости примерно в 3 раза
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускоряем Selenium-тесты