Comments 19
А чем это отличается от обычно работы с Selenium через создание обычного java файла, импортирования нужных пакетов и написания тех же самых тестов? Без лишних проектов, архетипов.
Еще 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.
т.е., если вам не нужно тестирование именно UI части, то вполне достаточно протестировать логику на странице с помощью HtmlUnit.
Я работаю не в Java стеке, поэтому не знаю что такое HtmlUnit. У нас в PHP есть отличная абстракция над браузером — Mink. Он позволяет абстрагироваться от реального драйвера веб-браузера и оперировать такими понятиями как «кликнуть на этой кнопке», «ввести это в поле», «найти на странице такую-то надпись», «перейти по такому-то URL» и т.д. А внутри в зависимости от нужд может быть драйвер либо Selenium (или phantomjs), либо обычный CURL (+ libxml для обработки xpath). В одном и том же тест-сюите могут быть рядом и JS тесты, и такие тесты через CURL, нужно только подменять драйвер на тот, который нужен в конкретном сценарии.
Да, естественно, если суть теста напрямую не связана с проверкой клиентского функционала в браузерах — то это не нужно делать с помощью селениума. Тот же PHPUnit, ScalaTest, хоть curl в bash-скрипте — вполне рабочее решение. Выбор в зависимости от принятых инструментов тестирования в проекте. Я с moot не спорил, просто предложил один из вариантов реорганизации тестов по уровням, т.к. считаю что со временем от большого количества тестов не уйти — это неизбежно. Можно тесты рефакторить время от времени, но и это тоже до определенной степени только сможет помочь. Рост уникального функционала -> рост числа тестов, любой развивающийся проект с грамотным сопровождением будет этому подвержен.
Будем использовать последнюю версию Selenium WebDriver
2.43 последняя
На момент написания статьи была именно та, которая указана в статье.
<зануда мод> 9-10 сентября</зануда мод>
Sign up to leave a comment.
Автоматизированное тестирование — это просто! Как я тестировал Печкина