Pull to refresh

Comments 19

А чем это отличается от обычно работы с Selenium через создание обычного java файла, импортирования нужных пакетов и написания тех же самых тестов? Без лишних проектов, архетипов.
Тем, что это quickstart с уже готовой архитектурой и зависимостями. Это та работа, которая проделывается при разработке нового проекта, так почему бы это не автоматизировать? ;)
Еще Allure прикрутите в качестве отчета и будет совсем удобно.
Конечно, следующая статья будет посвящена HTML Elements и Allure.
У меня вышло 37 тестов на проверку email

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

Да, такое разделение реализовать достаточно сложно, долго и дорого. Но это действительно полезно для больших, долгоживущих проектов.
Вы молодец, что освещаете эту тему. Я занимался автоматизацией тестирование на большущем проекте. И знаете к какому выводу я пришел? Если можно без Селениума — лучше без него. К сожалению, драйвера еще очень глючные и с каждым обновлением браузера, надо обновлять версию драйвера. Как ни печально, m00t прав.
Я для себя решил так: по возможности (если не сильно много JS на страницах) использовать для таких тестов не реальный браузер, а просто curl. И только на тех сценариях, которые юзают JS, подключать реальный браузер через Selenium (или phantomjs). Ну и не стоит забывать про остальные более быстрые и дешевые тесты, не тестирующие непосредственно UI.
использовать для таких тестов не реальный браузер, а просто curl

А можно пример для запуска теста на нескольких версиях браузера в параллель?
Не совсем понял, о каком примере идет речь. Поясню, что я имею ввиду. Скажем, у нас есть форма логина без всякого JS. Нету смысла запускать реальный браузер для того, чтобы протестировать работает она или нет. Достаточно сделать GET CURL запрос на /login, прочитать все данные из нужной <form>, отправить правильно сформированный POST запрос с этими данными на какой-нибудь /login_check (или как там где), проверить наличие нужной строки в полученном HTML (например «You are logged in as Username» или «Wrong credentials»). Для таких вещей нету необходимости запускать этот тест в 5 версиях разных браузеров.
может уж лучше тогда HtmlUnit использовать для этого?
т.е., если вам не нужно тестирование именно UI части, то вполне достаточно протестировать логику на странице с помощью HtmlUnit.
Я работаю не в Java стеке, поэтому не знаю что такое HtmlUnit. У нас в PHP есть отличная абстракция над браузером — Mink. Он позволяет абстрагироваться от реального драйвера веб-браузера и оперировать такими понятиями как «кликнуть на этой кнопке», «ввести это в поле», «найти на странице такую-то надпись», «перейти по такому-то URL» и т.д. А внутри в зависимости от нужд может быть драйвер либо Selenium (или phantomjs), либо обычный CURL (+ libxml для обработки xpath). В одном и том же тест-сюите могут быть рядом и JS тесты, и такие тесты через CURL, нужно только подменять драйвер на тот, который нужен в конкретном сценарии.
Да, естественно, если суть теста напрямую не связана с проверкой клиентского функционала в браузерах — то это не нужно делать с помощью селениума. Тот же PHPUnit, ScalaTest, хоть curl в bash-скрипте — вполне рабочее решение. Выбор в зависимости от принятых инструментов тестирования в проекте. Я с moot не спорил, просто предложил один из вариантов реорганизации тестов по уровням, т.к. считаю что со временем от большого количества тестов не уйти — это неизбежно. Можно тесты рефакторить время от времени, но и это тоже до определенной степени только сможет помочь. Рост уникального функционала -> рост числа тестов, любой развивающийся проект с грамотным сопровождением будет этому подвержен.
С большим кол-вом UI тестов да, многие описанные вами подходы помогут. Другое дело, что по возможности стоит все-таки стараться не делать огромное кол-во этих UI браузерных тестов. Например «37 тестов на проверку email» это явно не то, для чего надо запускать Selenium (по моему мнению).
Будем использовать последнюю версию Selenium WebDriver

2.43 последняя
На момент написания статьи была именно та, которая указана в статье.
[зануда мод] написание статьи != публикация статьи [/зануда мод]
Sign up to leave a comment.

Articles