Если вы когда-либо занимались автоматизацией тестирования веб приложений, то скорее всего у вас возникал вопрос: какой же он – идеальный фреймворк? И как выбрать наиболее удобный инструмент позволяющий быстро и качественно оценить результаты работы автотестов?
Ответ прост, как и на вопрос «сколько будет дважды два?». Кто ответил «5», «7» или «2» смело продолжайте читать этот пост. А кто ответил «4» тем более может найти здесь для себя что-то полезное. В этой статье вы не увидите ни строчки кода, только мои впечатления от знакомства с JDI фреймворком и облачной платформой для запуска тестов SauceLabs. Вот она интрига, итак, поехали…
Ближе к теме. Я работал некоторое время на проекте с использованием Selenium WebDriver в качестве базы для построения тестового фреймворка. Также применялся неплохой инструмент собственной разработки, анализирующий результаты прогона тестов с широким функционалом. Тесты запускались удаленно на виртуальных машинах, под которые был выделен специальный сервер. Не вдаваясь в подробности того, как все было устроено, использование WebDriver для написания тестовых сценариев на практике помогло мне обратить внимание на множество нюансов, без хорошего понимания которых легким движением руки фреймворк может развалиться как карточный домик. Другим необходимым навыком для автоматизатора является не только способность написать стабильный тест, но и в случае его падения, быстро разобраться с причиной, чтобы дать актуальный и по возможности однозначный фидбэк команде разработчиков. Или же внести правки в сам падающий тест. Тут нужно и понимание логики работы тестируемого приложения, и грамотная настройка логирования и конечно же возможность просмотреть историю результатов прогонов автотестов за некоторый период времени.
Разбирая впоследствии проектное приложение по кирпичикам и собирая заново как конструктор Lego все постепенно встало на свои места. Казалось-бы, чего проще, используй аналогичную модель на других проектах и будет тебе счастье. Но в IT, на мой взгляд, так не работает. Будучи в этой сфере, ты постоянно находишься в поиске и открываешь для себя новые технологии. И буквально две недели назад я столкнулся с альтернативной базой построения тестового фреймворка под названием JDI. А точнее, JDI-light, написанный поверх WebDriver. Первым вопросом что пришел мне в голову был – «зачем?». Зачем дополнительная прослойка между мной как тестировщиком и довольно неплохо зарекомендовавшим себя инструментом от Selenium?
После небольшого погружения в JDI, мой ответ будет следующим: если технология позволяет с минимумом затрат и усилий на ее внедрение выполнить одну и ту же работу эффективнее, то она имеет право на существование. Более того, на рынке выживает тот, кто может быстрее адаптироваться к новым условиям. Но нельзя сбрасывать со счетов и тот факт, что каким бы современным ни был молоток, но если начать забивать им не гвозди, а к примеру шурупы, то это будет как минимум менее эффективным по сравнению с применением шуруповерта.
Ну и резонный вопрос: насколько же просто начать использовать JDI?
Кроме этих действий потребуется немного перестроить свое прежнее видение того, как описывать веб элементы, сами страницы и конечно же как оформлять сами тестовые сценарии. Исходя из своего опыта могу сказать, что мне на это потребовалось 3-4 дня с беглым просмотром документации и оказалось довольно просто и даже приятно.
Кого-то может расстроить введение дополнительной типизации веб элементов. Но JDI типизация дает ряд преимуществ: от сокращения в разы количества набираемого кода и соответственно улучшения его читаемости до предоставления широкого набора дополнительного функционала «из коробки», который ранее приходилось также самому имплементировать в объектах представлений страниц. А если вдруг понадобиться определить свой пользовательский тип или дописать какие-то хитрые действия с элементом, то механизм наследования и полиморфизм в данном случае все также продолжают работать.
Перечисление фишек и плюшек JDI можно продолжать еще очень долго, но не будем заострять на этом внимание, так как документация с примерами использования и шаблонами проектов для старта представлена на github в довольно удобном для восприятия виде.
И еще один лайфхак. Взаимодействие с различными инструментами также просто настраивается, как и легко интегрируется Selenium WebDriver с, например, Selenoid, BrowserStack, Applitools или SauceLabs. В общем, пока одни плюсы.
Я, собственно, так же недавно поближе смог познакомиться с возможностями, которые предоставляет SauceLabs и могу отметить их привлекательность, хотя пробный бесплатный период его использования длится всего две недели и существует ограничение по общей длительности запускаемых на сервисе тестов (1ч 35 мин). Есть еще один минус, связанный с довольно частыми проблемами при регистрации пользователя на указанном ресурсе. Я также столкнулся с подобной коллизией, однако, короткая переписка с представителем техподдержки помогла-таки воспользоваться бесплатным тестовым периодом.
SauceLabs предоставляет обширную коллекций конфигураций операционных систем, браузеров и устройств. В документации заявлено, что при наличии правильной многопоточной конфигураций тесты будут выполняться параллельно в пакетах по 18 тестов за раз, планируя новый пакет каждый раз после его завершения. К тестам пишется лог, делаются скриншоты и видео. Говорится о возможности запустить, к примеру, упавший тест в ручном режиме. Но у меня это не получилось, вероятно, эта возможность появляется только после приобретения подписки.
И как же подключить JDI проект к SauceLabs? Очень просто. Зайти в проперти файл и раскомментировать одну строку ‘remote.type=sauce’, это если указанное вами месторасположение при регистрации в SauceLabs обрабатывается европейским датацентром. А если американским, то в том же файле раскомментировать еще одну строку ‘driver.remote.url’ и заменить url на тот который будет указан в вашем SauceLabs профиле. Если не хотите хардкодить свои данные для доступа к ресурсу в самом проекте, то следует назначить две переменные окружения
На этом мой обзор JDI и его интеграции с Saucelabs подошел к концу. Какой вывод я сделал для себя: не бывает идеальных инструментов, но есть те, которые в определенных обстоятельствах могут значительно облегчить труд программиста. И я добавил JDI в свой набор претендентов на то, чтобы быть предложенным будущему заказчику проекта для автоматизации тестирования. Saucelabs, как готовой сервис облачного тестирования, теперь так же будет находиться в моем поле зрения.
Полезные ссылки:
JDI проект
Шаблоны для быстрого старта
Примеры использования
Документация
Документация
Ответ прост, как и на вопрос «сколько будет дважды два?». Кто ответил «5», «7» или «2» смело продолжайте читать этот пост. А кто ответил «4» тем более может найти здесь для себя что-то полезное. В этой статье вы не увидите ни строчки кода, только мои впечатления от знакомства с JDI фреймворком и облачной платформой для запуска тестов SauceLabs. Вот она интрига, итак, поехали…
Ближе к теме. Я работал некоторое время на проекте с использованием Selenium WebDriver в качестве базы для построения тестового фреймворка. Также применялся неплохой инструмент собственной разработки, анализирующий результаты прогона тестов с широким функционалом. Тесты запускались удаленно на виртуальных машинах, под которые был выделен специальный сервер. Не вдаваясь в подробности того, как все было устроено, использование WebDriver для написания тестовых сценариев на практике помогло мне обратить внимание на множество нюансов, без хорошего понимания которых легким движением руки фреймворк может развалиться как карточный домик. Другим необходимым навыком для автоматизатора является не только способность написать стабильный тест, но и в случае его падения, быстро разобраться с причиной, чтобы дать актуальный и по возможности однозначный фидбэк команде разработчиков. Или же внести правки в сам падающий тест. Тут нужно и понимание логики работы тестируемого приложения, и грамотная настройка логирования и конечно же возможность просмотреть историю результатов прогонов автотестов за некоторый период времени.
Разбирая впоследствии проектное приложение по кирпичикам и собирая заново как конструктор Lego все постепенно встало на свои места. Казалось-бы, чего проще, используй аналогичную модель на других проектах и будет тебе счастье. Но в IT, на мой взгляд, так не работает. Будучи в этой сфере, ты постоянно находишься в поиске и открываешь для себя новые технологии. И буквально две недели назад я столкнулся с альтернативной базой построения тестового фреймворка под названием JDI. А точнее, JDI-light, написанный поверх WebDriver. Первым вопросом что пришел мне в голову был – «зачем?». Зачем дополнительная прослойка между мной как тестировщиком и довольно неплохо зарекомендовавшим себя инструментом от Selenium?
После небольшого погружения в JDI, мой ответ будет следующим: если технология позволяет с минимумом затрат и усилий на ее внедрение выполнить одну и ту же работу эффективнее, то она имеет право на существование. Более того, на рынке выживает тот, кто может быстрее адаптироваться к новым условиям. Но нельзя сбрасывать со счетов и тот факт, что каким бы современным ни был молоток, но если начать забивать им не гвозди, а к примеру шурупы, то это будет как минимум менее эффективным по сравнению с применением шуруповерта.
Ну и резонный вопрос: насколько же просто начать использовать JDI?
- Если проект новый, то просто подключаем зависимости на jdi-light, на тестовый фреймворк (testing, junit) и инструмент для репортинга в зависимости от предпочтений. И у нас по дефолту уже будет готовый к использованию веб драйвер (chrome), а также за нас реализованное, приятное глазу логирование. Более тонкие настройки можно сделать, раскомментировав или заменив дефолтные значения в проперти файле.
- Если проект уже некоторое время существует, то нужно заменить зависимость selenium на jdi-ligh и если у вас применяется паттерн PageFactory, то потребуется в коде заменить импорт этой фабрики с selenium на jdi. Но здесь обольщаться не стоит. Да проект может даже запуститься с первого раза, но, чтобы получить все бенефиты, которые предоставляет JDI придется еще изрядно потрудиться, но это уже тема для другого поста.
Кроме этих действий потребуется немного перестроить свое прежнее видение того, как описывать веб элементы, сами страницы и конечно же как оформлять сами тестовые сценарии. Исходя из своего опыта могу сказать, что мне на это потребовалось 3-4 дня с беглым просмотром документации и оказалось довольно просто и даже приятно.
Кого-то может расстроить введение дополнительной типизации веб элементов. Но JDI типизация дает ряд преимуществ: от сокращения в разы количества набираемого кода и соответственно улучшения его читаемости до предоставления широкого набора дополнительного функционала «из коробки», который ранее приходилось также самому имплементировать в объектах представлений страниц. А если вдруг понадобиться определить свой пользовательский тип или дописать какие-то хитрые действия с элементом, то механизм наследования и полиморфизм в данном случае все также продолжают работать.
Перечисление фишек и плюшек JDI можно продолжать еще очень долго, но не будем заострять на этом внимание, так как документация с примерами использования и шаблонами проектов для старта представлена на github в довольно удобном для восприятия виде.
И еще один лайфхак. Взаимодействие с различными инструментами также просто настраивается, как и легко интегрируется Selenium WebDriver с, например, Selenoid, BrowserStack, Applitools или SauceLabs. В общем, пока одни плюсы.
Я, собственно, так же недавно поближе смог познакомиться с возможностями, которые предоставляет SauceLabs и могу отметить их привлекательность, хотя пробный бесплатный период его использования длится всего две недели и существует ограничение по общей длительности запускаемых на сервисе тестов (1ч 35 мин). Есть еще один минус, связанный с довольно частыми проблемами при регистрации пользователя на указанном ресурсе. Я также столкнулся с подобной коллизией, однако, короткая переписка с представителем техподдержки помогла-таки воспользоваться бесплатным тестовым периодом.
SauceLabs предоставляет обширную коллекций конфигураций операционных систем, браузеров и устройств. В документации заявлено, что при наличии правильной многопоточной конфигураций тесты будут выполняться параллельно в пакетах по 18 тестов за раз, планируя новый пакет каждый раз после его завершения. К тестам пишется лог, делаются скриншоты и видео. Говорится о возможности запустить, к примеру, упавший тест в ручном режиме. Но у меня это не получилось, вероятно, эта возможность появляется только после приобретения подписки.
И как же подключить JDI проект к SauceLabs? Очень просто. Зайти в проперти файл и раскомментировать одну строку ‘remote.type=sauce’, это если указанное вами месторасположение при регистрации в SauceLabs обрабатывается европейским датацентром. А если американским, то в том же файле раскомментировать еще одну строку ‘driver.remote.url’ и заменить url на тот который будет указан в вашем SauceLabs профиле. Если не хотите хардкодить свои данные для доступа к ресурсу в самом проекте, то следует назначить две переменные окружения
SAUCE_USERNAME и SAUCE_ACCESS_KEY, значения которых также можно найти в своем профиле. И все, теперь можно в своей любимой IDE нажать кнопку старт и увидеть прогон тестов в онлайн режиме. Или же, попросить maven запустить нужные тесты, передав ему в качестве параметров командной строки – DSAUCE_USERNAME={username} – DSAUCE_ACCESS_KEY={accessKey}.На этом мой обзор JDI и его интеграции с Saucelabs подошел к концу. Какой вывод я сделал для себя: не бывает идеальных инструментов, но есть те, которые в определенных обстоятельствах могут значительно облегчить труд программиста. И я добавил JDI в свой набор претендентов на то, чтобы быть предложенным будущему заказчику проекта для автоматизации тестирования. Saucelabs, как готовой сервис облачного тестирования, теперь так же будет находиться в моем поле зрения.
Полезные ссылки:
JDI проект
Шаблоны для быстрого старта
Примеры использования
Документация
Документация