Я иногда использую ещё один подход, не описанный в этой статье — прокси между браузером и тестируемым приложением, который перехватывает запросы на загрузку файлов и сам их загружает, а в браузер отдаёт страничку «файл загружен, находится тут».
Кто-то нашёл баги (неважно кто — штатные тестировщики/бета-тестеры/рядовые пользователи/коллеги-разработчики/НачПроекта), но разработчики не могут/не хотят/не имеют времени их исправлять, поэтому качество не улучшается.
Заходим селениумом на нужную страницу, подкачиваем из внешнего файла JS-тесты для этой страницы, селениумом заливаем их в браузер, дёргаем пускач, тесты добегают — а дальше селениум проверяет всё остальное. На следующей страничке повторяем. Естественно, делаем опцию, чтобы можно было отключать модульные тесты, когда надо прогнать только интеграционные.
Как раз и предлагаю — сначала на QUnit делаем модульные тесты, а потом используем в Selenium движок HtmlUnitDriver, который имеет ограниченные возможности по поддержке AJAX, но зато быстрый, и проверяем логику интегрально.
Если эти штуки тестировать не надо — тогда в Selenium можно вообще врубить HtmlUnitDriver, и не будет ни браузера, ни нативных ивентов, но зато будет очень быстро.
Если отключить использование нативных ивентов — будет, грубо говоря, только onChange в конце. Если вставлять через клипборд — примерно то же самое. И по скорости, и по набору событий.
При использовании нативных ивентов на каждый вводимый символ генерируется полный набор событий — keyDown, keyPress, keyUp. Отключив их, вы полностью лишите себя возможности тестировать корректность работы, скажем, автопродолжения или валидации в процессе ввода.
Про несколько браузеров согласен. Виртуалки рулят (с отключенной интеграцией клипборда, естественно).
Отключаем native events — и половина обработчиков JQuery перестаёт срабатывать, ага.
Ускорять ввод текста, если это самое узкое место лучше другим способом: вводить текст «куском» — запихнули в клипборд, поставили фокус на поле ввода, послали Ctrl-C, и всё мигом вставилось.
Да я что, против что ли? Если удастся программиста развести на написание эмулятора — считай, повезло :) Но вообще-то они тоже делом занимаются, так что прежде чем отвлекать их, стоит подумать — а не могу ли я это сам сделать?
Конечно, если квалификация не позволяет, тогда понятно. Но мы же начали обсуждать посылку про то, что «программист кодит быстрее, поэтому пусть он эмулятор и пишет». Вот с этим тезисом я не согласен.
Эффективность не связана с количеством отработанного времени. Напротив, из двух людей более эффективным следует считать того, кто одну и ту же задачу делает быстрее. То есть — работает меньше :)
Несмотря на то, что Влад ответил «нет» я таки отвечу «да» на первый пункт :)
Да, мы обсуждали вопрос, как привлечь больше участников. Точнее говоря, мы обсуждали, что надо сделать, чтобы это было интересно не только самим участникам, но и их работодателям. Чтобы ситуация была «win-win-win».
А так — организатор конференции выигрывает, участник, если за него заплатил работодатель, тоже (будем считать, что ему понравилась конференция :)), а вот с самим работодателем — непонятка. За что он заплатил? Что он получит взамен?
Я иногда использую ещё один подход, не описанный в этой статье — прокси между браузером и тестируемым приложением, который перехватывает запросы на загрузку файлов и сам их загружает, а в браузер отдаёт страничку «файл загружен, находится тут».
Насколько я понял, пока реализовано только соединение с JUnit, планируете сделать варианты с другими тестовыми фреймворками?
А что именно плохо генерируется? Какие команды не попадают в сгенерированный код?
Интересно, причём тут тестирование вообще? :)
При использовании нативных ивентов на каждый вводимый символ генерируется полный набор событий — keyDown, keyPress, keyUp. Отключив их, вы полностью лишите себя возможности тестировать корректность работы, скажем, автопродолжения или валидации в процессе ввода.
Про несколько браузеров согласен. Виртуалки рулят (с отключенной интеграцией клипборда, естественно).
Ускорять ввод текста, если это самое узкое место лучше другим способом: вводить текст «куском» — запихнули в клипборд, поставили фокус на поле ввода, послали Ctrl-C, и всё мигом вставилось.
Конечно, если квалификация не позволяет, тогда понятно. Но мы же начали обсуждать посылку про то, что «программист кодит быстрее, поэтому пусть он эмулятор и пишет». Вот с этим тезисом я не согласен.
Да, мы обсуждали вопрос, как привлечь больше участников. Точнее говоря, мы обсуждали, что надо сделать, чтобы это было интересно не только самим участникам, но и их работодателям. Чтобы ситуация была «win-win-win».
А так — организатор конференции выигрывает, участник, если за него заплатил работодатель, тоже (будем считать, что ему понравилась конференция :)), а вот с самим работодателем — непонятка. За что он заплатил? Что он получит взамен?