Автоматизированное тестирование — это просто! Как я тестировал Печкина

[NCNecros]

А чем это отличается от обычно работы с Selenium через создание обычного java файла, импортирования нужных пакетов и написания тех же самых тестов? Без лишних проектов, архетипов.

[SkvPavel]

Тем, что это quickstart с уже готовой архитектурой и зависимостями. Это та работа, которая проделывается при разработке нового проекта, так почему бы это не автоматизировать? ;)

[NCNecros]

Понятно, спасибо.

[vaniaPooh]

Еще Allure прикрутите в качестве отчета и будет совсем удобно.

[SkvPavel]

Конечно, следующая статья будет посвящена HTML Elements и Allure.

[m00t]

У меня вышло 37 тестов на проверку email

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

[slava_k]

В таком случае можно сгруппировать тесты по разному уровню важности/потенциальной стоимости исправления, критичные тесты проводить всегда автоматизированно и в фоне после каждой промежуточной сборки, финальный билд в таком случае выглядел бы как доводка незначительных проблем/тестов среднего и менее уровня важности.

Да, такое разделение реализовать достаточно сложно, долго и дорого. Но это действительно полезно для больших, долгоживущих проектов.

[marshinov]

Вы молодец, что освещаете эту тему. Я занимался автоматизацией тестирование на большущем проекте. И знаете к какому выводу я пришел? Если можно без Селениума — лучше без него. К сожалению, драйвера еще очень глючные и с каждым обновлением браузера, надо обновлять версию драйвера. Как ни печально, m00t прав.

[m00t]

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

[SkvPavel]

использовать для таких тестов не реальный браузер, а просто curl

А можно пример для запуска теста на нескольких версиях браузера в параллель?

[m00t]

Не совсем понял, о каком примере идет речь. Поясню, что я имею ввиду. Скажем, у нас есть форма логина без всякого JS. Нету смысла запускать реальный браузер для того, чтобы протестировать работает она или нет. Достаточно сделать GET CURL запрос на /login, прочитать все данные из нужной <form>, отправить правильно сформированный POST запрос с этими данными на какой-нибудь /login_check (или как там где), проверить наличие нужной строки в полученном HTML (например «You are logged in as Username» или «Wrong credentials»). Для таких вещей нету необходимости запускать этот тест в 5 версиях разных браузеров.

[Borz]

может уж лучше тогда HtmlUnit использовать для этого?
т.е., если вам не нужно тестирование именно UI части, то вполне достаточно протестировать логику на странице с помощью HtmlUnit.

[m00t]

Я работаю не в Java стеке, поэтому не знаю что такое HtmlUnit. У нас в PHP есть отличная абстракция над браузером — Mink. Он позволяет абстрагироваться от реального драйвера веб-браузера и оперировать такими понятиями как «кликнуть на этой кнопке», «ввести это в поле», «найти на странице такую-то надпись», «перейти по такому-то URL» и т.д. А внутри в зависимости от нужд может быть драйвер либо Selenium (или phantomjs), либо обычный CURL (+ libxml для обработки xpath). В одном и том же тест-сюите могут быть рядом и JS тесты, и такие тесты через CURL, нужно только подменять драйвер на тот, который нужен в конкретном сценарии.

[slava_k]

Да, естественно, если суть теста напрямую не связана с проверкой клиентского функционала в браузерах — то это не нужно делать с помощью селениума. Тот же PHPUnit, ScalaTest, хоть curl в bash-скрипте — вполне рабочее решение. Выбор в зависимости от принятых инструментов тестирования в проекте. Я с moot не спорил, просто предложил один из вариантов реорганизации тестов по уровням, т.к. считаю что со временем от большого количества тестов не уйти — это неизбежно. Можно тесты рефакторить время от времени, но и это тоже до определенной степени только сможет помочь. Рост уникального функционала -> рост числа тестов, любой развивающийся проект с грамотным сопровождением будет этому подвержен.

[m00t]

С большим кол-вом UI тестов да, многие описанные вами подходы помогут. Другое дело, что по возможности стоит все-таки стараться не делать огромное кол-во этих UI браузерных тестов. Например «37 тестов на проверку email» это явно не то, для чего надо запускать Selenium (по моему мнению).

[f1r3]

Будем использовать последнюю версию Selenium WebDriver

2.43 последняя

[SkvPavel]

На момент написания статьи была именно та, которая указана в статье.

[f1r3]

<зануда мод> 9-10 сентября</зануда мод>

[Borz]

[зануда мод] написание статьи != публикация статьи [/зануда мод]