selenium webdriver позволяет записать ручные действия пользователя и превратить их в код автотеста

Интеграционное тестирование web-приложения с Selenium WebDriver

Интеграционное тестирование (в отличие от Unit- или модульного тестирования) это тестирование не отдельных атомарных компонентов системы (классов) а результата их взаимодействия между собой в какой-либо среде.

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

О том, как можно Unit-тестировать JavaScript я писал ранее, сейчас же расскажу о процессе интеграционного тестирования, применяемого в команде.

Selenium

WebDriver

Selenium WebDriver это набор «биндингов» к разным языкам (C#, Java), позволяющий отдавать различные команды «подчиненному» браузеру.

Для каждого браузера имеется своя реализация WebDriver (FireFoxDriver, InternetExplorerDriver, ChromeDriver — сейчас включены в поставку, OperaSoftware разработали OperaDriver). Существует также «виртуальный» HtmlUnitDriver. В отличии от «браузерных» реализаций он не требует установленного браузера и за счет этого работает быстрее и платформонезависим, но есть и минусы — HtmlUnitDriver имеет «свою» реализацию JavaScript и потому поведение «богатых» веб-приложений может в нем отличаться. Для своих задач мы используем «браузерные» реализации, это позволяет проверить приложение именно в той среде, в которой оно будет исполняться впоследствии.

Что умеет WebDriver

Среда исполнения тестов

В качестве языка для написания тестов была выбрана Java. Среда для исполнения — JUnit4.

DISCLAIMER: Не претендую на звание крутого джависта, посему если старшие коллеги найдут огрехи и всякие прочие «антипаттерны» — с удовольствием выслушаю в комментариях.

Базовый абстрактный класс веб-тестов.

Конкретный класс с набором тестов (для простоты убраны некоторые проверки, например на то, что элемент по CSS-селектору действительно найден и доступен на странице)

Все тесты запускаются с помощью отдельного таска Ant-билда:

Данный таск прогонит все известные тесты из классов, чьи имена начинаются с Test под браузерами Firefox и InternetExplorer. В зависимостях таски с базовой инициализацией, компиляцией и выгрузкой скомпилированных тестов на тестовую площадку.

Фишки-плюшки

Некоторые «браузерные» реализации (Firefox, Opera, Chrome) поддерживают снятие скриншотов. Это может быть полезно дабы зафиксировать визуальное состояние, в котором пребывала тестовая страница в момент, когда тест не прошел. Для этого подойдет функционал JUnit4 — TestWatchman.

Добавим переменную с путем к папке со скриншотами в Ant-билд

Интеграция

В текущей реализации Ant-билд гоняется через Jetbrains TeamCity. Запуск билда настроен на сброс кода в SVN. Интеграционные тесты — часть общей процедуры тестирования. При провале любого из интеграционных тестов снимается скриншот и публикуется как «артефакт» билда — можно видеть не только какие тесты «отъехали» после сброса в транк какого-либо функционала, но и увидеть «как» они «отъехали».

В настоящее время используется тестирование под IE и Firefox, Chrome не подключен по причине некоторых трудностей с интеграцией (судя по всему в ChromeDriver присутствуют некоторые ошибки, не позволяющие нормально искать элементы на странице в некоторых случаях — по состоянию на 2.0b1, сейчас доступна 2.0b2 но работу с ней пока не пробовали)

Источник

Разработка автоматизированных тестов на базе Selenium WebDriver 2.x

Здравствуйте, уважаемое Хабросообщество! Хочу поделиться своим способом разработки и организации написания автоматизированных тестов на базе Selenium WebDriver 2.x на языке программирования C#.
Сразу скажу, что многие тезисы, принципы и методы разработки придуманы не мной (и, наверное, не моими учителями).
Возможно, этот пост поможет тем, кто только-только начинает заниматься автоматизированным тестированием Web-приложений.

Подготовка

Для разработки автоматизированных тестов с использованием Selenium нам необходимы следующие компоненты:
Среда разработки, в нашем случае Visual Studio;
Программа NUnit для автоматического прогона написанных тестов (скачать можно здесь: www.nunit.org/index.php?p=download);
Браузер Mozilla Firefox с двумя установленными для него плагинами: FireBug и FirePath (в данной статье не используются).

Настройка среды разработки

Для написания автоматизированных тестов необходимо создать новый проект типа Class Library (можно создать и консольное приложение, но не в нашем случае). Желательно дать ему название, которое ассоциируется с названием тестируемого проекта. Также, желательно создать тестовый проект в самом солюшене с тестируемым проектом.
После создания тестового проекта к нему необходимо подключить 3 специальные библиотеки для тестов:
NUnit (nunit.framework) – библиотека для непосредственного прогона автоматизированных тестов (не только для Selenium);
WebDriver + WebDriver.Support – непосредственно библиотеки Selenium’a.
Подключить библиотеки к тестовому проекту можно через NuGet или вручную, скачав последнюю версию с сайта code.google.com/p/selenium/downloads/list.

Построение архитектуры тестового проекта

Базовый класс

До начала написания самих автоматизированных тестов вначале нам необходимо создать вспомогательные классы.
В тестовом проекте добавим новый класс и назовем его SeleniumTestBase.cs (можно и по-другому). Объявим этот класс как public abstract, так как именно от этого класса будут наследоваться в дальнейшем все тестовые классы. Также к классу необходимо добавить атрибут [TestFixture], что обозначает класс как тест-класс. В данном классе объявляются те поля и методы, которые необходимы для прохождения любого теста.
В этом классе обязательно объявляем поле:
protected IWebDriver Driver; — это экземпляр драйвера браузера, который создается перед прогоном теста(-ов). Существует 4 вида драйверов (+ несколько в стадии разработки): FirefoxDriver, InternetExplorerDriver, ChromeDriver, HtmlUnitDriver (кроссплатформенный виртуальный браузер без графической составляющей).

Также в классе объявим 4 метода (хотя некоторые могут быть пустыми или\и не определятся вообще):
public void TestInitialize() с атрибутом [TestFixtureSetUp] – метод с данным атрибутом будет вызываться один раз перед прогоном тестов из какого-либо тестового класса (если классов несколько, то метод будет вызываться перед тестами из первого класса, потом перед методами второго класса и так далее). В этом классе желательно присвоить переменной Driver конкретное значение, например:
Driver = new FirefoxDriver();

public void TestCleanup() с атрибутом [TestFixtureTearDown] – принцип работы как у предыдущего метода, но только после прогона тест-класса. В данном классе желательно закрыть драйвер браузера, так как при прогоне следующего тест-класса обязательно создастся новый экземпляр драйвера браузера (в итоге могут остаться открытыми многие экземпляры драйвера браузера, а оперативная память не резиновая):
Driver.Quit();

public void OneTearDown() с атрибутом [TearDown] – метод вызывается после прогона каждого отдельного теста. В этом методе, например, можно почистить куки браузера перед каждым новым тестом:
Driver.Manage().Cookies.DeleteAllCookies();

public void OneSetUp() с атрибутом [SetUp] – метод вызывается перед прогоном каждого отдельного теста. Например, можно разворачивать окно браузера на весь экран при прогоне теста (неактуально для HtmlUnitDriver):
Driver.Manage().Window.Maxmize();

Обёртка

Разница между Wrapper.cs и SeleniumTestBase.cs в том, что в первом объявляются методы, которые вызываются внутри тестов (и даже внутри SeleniumTestBase), а во втором – методы, которые вызываются до или после тестов.
После создания вспомогательных тестов уже создаем обычные тестовые классы.

Таким образом, архитектура тестового проекта выглядит так:

Пример написания теста

[Test] – атрибут, который определяет, что данный метод является тестовым.
Timeot(int millSec) – работает только вместе с атрибутом Test – указывает максимально допустимое количество миллисекунд на прохождение теста. Если таймаут превышен, тест падает сразу (даже во время выполнения) и считается непройденным.
public void – тест должен иметь именно такой модификатор доступа и не должен возвращать никакое значение для корректной работы теста.
Driver.Navigate().GoToUrl(Wrapper.GetUrl()) — драйвер браузера откроет нам страничку Яндекса.
Assert.IsTrue(Driver.Title == «Яндекс») — непосредственная проверка, в данном случае тест проверяет, что тайтл странички есть «Яндекс», в этом случае тест считается пройденным, иначе тест не пройден.

Запуск тестов

Дополнительная информация

Наиболее быстрым драйвером браузера считается ChromeDriver. Угадайте самый медленный.

Для ChromeDriver и InternetExplorerDriver необходимо скачать дополнительно приложение драйвера и положить его в директорию с проектом.

Также в тестах используются атрибуты:
[TestCase(var v1, …, var vOver9000)] – используется, если тест должен перебрать несколько возможных данных входа. Перед тестом можно написать любое количество тест-кейсов. Для корректной работы тест-методу необходимо передавать столько параметров, сколько переменных прописано в тест-кейсе. Тест-кейсы должны быть идентичными по составу (нельзя перед тестом писать тест-кейсы с 1 переменной, а потом с 2-мя). Пример:

Здесь 16 тестов и только 4 из них пройдут.

Советы

Возьмите в привычку: один тест – один Assert. Желательно не нарушать совсем или нарушать в крайних случаях (при большом количестве проверок в тесте читабельность кода снижается).

Многие селекторы в коде могут повторяться по нескольку раз. Лучше их выносить в отдельные строковые константы, так как верстка сайта может постоянно меняться, а вместе с ней и селекторы. Тогда при изменении селектора его придется менять лишь в одном месте, а не в 20-ти местах по всему проекту.

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

По стандартам качества, таймаут на загрузку страницы в браузере равен 10 секунд. Ставьте таймаут по поиску элемента на странице в 11 секунд (максимум 12).

С некоторыми элементами на странице невозможно взаимодействовать при помощи Selenium + C#. В данном случае следует использовать JavaScript + JQuery для доступа к таким элементам страницы. Пример:

Для удобства прогона тестов (NUnit не самая удобная вещь) можно дополнительно установить в Visual Studio плагин ReSharper, который с легкостью позволяет запускать тесты, а также смотреть результаты прогона. Но в отличие от NUnit, ReSharper – платное дополнение.

Заключение

Данную статью, к сожалению, нельзя считать руководством по написанию Selenium-тестов, так как здесь не описаны методы и способы тестирования Web-приложений. В частности, класс Assert для проверки условий и Selenium-методы поиска элементов на Web-странице. Этому будет посвящена другая статья.
Надеюсь, что изложенный мною подход будет использован кем-либо для написания своих автоматизированных тестов.
Спасибо за внимание!

Источник

Автоматизация тестирования веб-приложения с использованием Selenium WebDriver, Python, и Behave

Перед началом

Тут я не буду подробно останавливаться на том, как искать элементы, и как взаимодействовать с ними при помощи selenium webdriver, а расскажу только о том, как можно легко и удобно писать и гонять тесты написанные на python с использованием behave.

1. Установка нужностей

Как лаконично подсказывает wiki:
Selenium — это инструмент для тестирования Web-приложений.

Так же про него много писали на Хабре:
тут, и тут даже есть частичный перевод не официальной документации

Теперь установим behave. Можно с использованием pip:
pip install behave

А можно скачать тут: behave на pypi
Что такое behave? Behave — это фрейморк для программирования через поведения в python-стиле(Что такое Behavior-driven development?).
Behave использует тесты написанные на натуральном языке, с логикой на python.
Он обладает несколькими серьезными плюсами:

+ Легкая установка
+ Отчеты в формате junit
+ Тесты может писать любой человек на естественном языке.
+ Есть возможность интеграции с jenkins (с другими CI, наверное, тоже)

Сравнение behave с похожими инструментами.
Когда все необходимое установлено можно приступать к настройке окружения для написания и выполнения тестов.

2. Настройка

Опционально можно добавить в директорию содержащую папку steps файл — environment.py c кодом который надо будет выполнять прежде или после определенных событий в тесте.
Подробное описание этого файла тут.
Наш пример будет максимально простым, поэтому мы не будем включать этот файл.

Итого, как выглядит наша директория в минимальной комплектации:

features/
features/everything.feature
features/steps/
features/steps/steps.py

пример из behave tutorial
Вот и вся настройка, можно писать первый тест!

3. Написание и запуск первого теста

Итак, скопируйте код ниже в файл firs_test.py.

Если лень смотреть код, то логика такая:
1. Открыть ya.ru
2. Клацнуть на кнопку «Найти»
3. Проверить, что на странице выдачи есть текст: «Задан пустой поисковый запрос»

Шаги из теста, по декораторам свяжутся с python функциями. (Декораторы обозначены знаком @)

Теперь запустим наш тест.
Перейдем в папку, где он лежит, и выполним команду:

Если все прошло хорошо, то отчет будет, примерно, таким:

Заключение

Здесь я привел только самое основное.
Фичи selenium неисчислимы, да и behave много чего умеет. В том числе, отчеты в формате junit и интеграцию с jenkis.
Спасибо за внимание, и хороших выходных!

Список использованных материалов

UPD: Если что-то в статье не очень хорошо написано, или чего-то не хватает, то можно высказаться в комментариях, или написать в личку мне, и мы вместе улучшим ее.

Источник

Selenium WebDriver на службе разработчика

Расшифровка доклада Дмитрия Костичева с Backend-stories // Видеоверсия внутри

Если вдруг у вас появилась необходимость интеграции на стороннем интернет-ресурсе, а разбираться в нем нет времени, на помощь придет Selenium. Дмитрий Костичев рассказал на примере своего проекта, как автоматизировать работу в браузере, не выходя из вашего сервиса.

Привет всем. Меня зовут Дмитрий и я сегодня поделюсь опытом использования Selenium в Backend-разработке. Для чего это вообще нужно? Selenium нужен для автоматизации взаимодействия с какими-то интернет-ресурсами, чтобы нивелировать человеческие факторы заполнений каких-то данных и т.д. Для разработки это может понадобиться в таких случаях, когда, например, на интернет-ресурсе не бывает API и так далее. И на примере моего проекта была задача — заполнить клиентские данные (перед этим сервис должен был правильно подготовить всю информацию) и зарегистрировать их на этом сайте, в данном случае MasterCard.

При дальнейшем рассмотрении этого сайта было выявлено, что тут нет api, к которому мы можем достучаться и все сделать. Вся обработка производится в JS-cкриптах, в которых ничего не понятно и данные все кодируются. Решение было принято — попробовать Selenium в этих целях, то есть мы прикрутим к Selenium весь наш сервис, который будет в какие-то определенны моменты проводить эту регистрацию.

В итоге, что же такое Selenium и как с ним работать? Проект Selenium состоит из библиотеки, которая общается с интерфейсом веб-драйвера под определенный браузер. Список доступных библиотек и браузеров приведен на слайде. И сейчас я покажу, как это примерно работает на моем проекте.

Посмотреть скринкаст или подробное видео в конце поста.

Сейчас сервис будет генерить файлик, сразу же его закачает на этот сайт и проверит, все ли успешно было зарегистрировано. Вот, собственно, он проклеивает, загружает и так далее. И сейчас он, наверное, прыгнет на то, что все будет успешно. Автоматизация достаточно быстро работает и не требует каких-то больших ресурсов. Все, как видно, отлично зарегистрировалось.

Как же все это приготовить? Библиотека Selenium имеет такие основные команды, как:

При работе с интернет-ресурсами, и в конечном итоге с Selenium есть некоторые паттерны проектирования. И один из них — page objects. Суть его заключается в том, что мы описываем в определенном классе все эти элементы. И дальше можем его переиспользовать и это выглядит проще. Вот, примерно так: вызываем команду open, даем page objects class и дальше можем использовать все его методы, например, работу с элементами.

Поиск элементов у нас осуществляется по DOM модели HTML страницы по таким селекторам, как xpath, css и другие. Основные их отличия, например между xpath и css, так это то, что xpath может ходить «вглубь», а также вверх и вниз. А css, наоборот, только вниз. То есть, это самые используемые селекторы.

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

Собственно, взаимодействие странички выглядит примерно так, это достаточно линейная обработка данных. В этом случае я разделил на шаги — переходы на странички. Здесь происходит заполнение данными и, непосредственно, загрузка файлами. В принципе, все достаточно просто. Примерно вот так выглядит pageobject-class, достаточно напоминает ДТО-шку. Просто описываем элементы, например, здесь в текущем случае PCSS Selectum. Это синтаксис Selenide.

Чтобы это все заработало, нам понадобится описание Remote-драйвера, чтобы подключиться к докер-контейнеру. Основные настройки, которые туда нужно прокинуть, это выбор браузера, который мы будем использовать и, собственное, разрешение и другие важные строки для браузера. Но для того, чтобы работать с докер-контейнером потребуются еще такие настройки как headless-режим. То есть, в текущем виде это будет крутиться на сервере. Этот режим отключает графику в браузере, поэтому он будет работать быстрее и занимать меньше ресурсов.

Далее это будет no Sandbox, который отключается безопасностью Chromium в этом случае, и можно будет исполнять свой код, JS или другой. Третий параметр нужен для того, чтобы Chromium нормально работал на unix машинах, правильно записывал темповые файлы. И четвертый, собственно, нужен для того, чтобы нам загружать файлы. И самое главное, у Remote-драйвера есть флаг, который позволяет загружать файл из локального хранилища, где работает приложение, уже через Remove драйвер.

Сейчас я покажу, как это работает с докер-контейнером. Загружаем докер-контейнер и само приложение. Он примерно также будет запускаться, то есть, в принципе, ничего нового не будет. Только здесь мы будем видеть взаимодействие в каких-то логах. В принципе, их также можно мониторить, с ними работать и так далее. Поэтому можно понять взаимодействие, что происходит. Это вывод из докер-контейнера с Chromium непосредственно, где браузер стоит.

В принципе, все отлично работает с докер-контейнером. Также все проверяется и успешно завершена регистрация. Далее, какие вообще проблемы можно было бы встретить в таком подходе? У меня была не столько проблема, сколько незнание. Передачи файлов в докер-контейнере как обычно все делают — черед volume. Но в этом случае, если еще хочется локально запускать, то нужно иметь две конфигурации для проекта, но, как оказалось, Remote драйвер умеет через флаг настраиваться. Он может передавать этот файл непосредственно через себя, и не нужны никакие дополнительные телодвижения.

Также придется следить за страничкой, с которой мы работаем — интернет-ресурсом. Потому что, в моем случае, это другая система, к которой никто не имеет отношения из моей команды, и за этим нужно тоже следить, мониторить по логам и так далее. Так же и с браузером, он постоянно обновляется, за ним нужно следить, поддержка может упасть. Ну в принципе, по логам можно как-то настроить и никаких проблем не будет.

В итоге, насколько все стало проще? Как мне показалось, я смог решить проблему взаимодействия с этим сайтом намного быстрее, чем если бы я разбирался в js-коде. То есть, разобраться в Selenium и во взаимодействии можно быстрее, чем с тем, что данные кодируются и неизвестно, как их перекодировать обратно. Основная штука — скорость в разработке.

Источник

Что такое Selenium WebDriver?

Эта статья является продолжением более общей статьи «Что такое Selenium?», в которой объясняется, какое положение занимает Selenium WebDriver среди других инструментов автоматизации веб-приложений.

Здесь я постараюсь рассказать более подробно о том, что такое Selenium WebDriver, и почему его бессмысленно сравнивать с TestComplete, QuickTest Pro и другими инструментами автоматизации тестирования. И дело не только в том, что Selenium WebDriver бесплатный и открытый – его столь же бессмысленно сравнивать с другими бесплатными инструментами, такими как Sahi или Robot Framework.

Потому что Selenium WebDriver – это не инструмент для автоматизации тестирования.

А что же это такое?

На этот вопрос можно дать несколько разных ответов, сначала я дам короткие ответы, а потом – более подробные.

Кроме того, я объясню, почему Selenium WebDriver имеет такой убогий и неудобный в использовании интерфейс (набор команд), почему он не генерирует красивые отчёты и почему несмотря на всё это он настолько популярен 🙂

На всякий случай оговорюсь, что хотя в этой статье речь идёт про WebDriver, многие аргументы справедливы и в отношении Selenium RC, но я не буду ничего говорить специально про эту устаревшую версию, потому что её место – на свалке истории.

Итак, что такое Selenium WebDriver?

По назначению Selenium WebDriver представляет собой драйвер браузера, то есть программную библиотеку, которая позволяет разрабатывать программы, управляющие поведением браузера.

Selenium WebDriver – это драйвер браузера

Наверняка каждый, кто сталкивался с компьютерами, даже не айтишник, знает слово «драйвер». Это такая маленькая программа, точнее программная библиотека, которая позволяет другим программам взаимодействовать с некоторым устройством. Драйвер принтера позволяет печатать что-нибудь на принтере. Драйвер диска позволяет читать и писать данные. Драйвер сетевой карты позволяет обмениваться данными с другими компьютерами по сети.

С драйвером пользователи не работают непосредственно. Они работают с прикладными программами, которые, посредством драйверов, взаимодействуют с теми или иными устройствами. Драйвер не имеет пользовательского интерфейса. Постойте, но ведь иногда бывает пользовательский интерфейс для настройки драйвера? Бывает. Но это интерфейс программы для настройки драйвера, а не самого драйвера. Драйвер имеет только программный интерфейс, его назначение состоит в том, чтобы дать возможность прикладным пользовательским программам взаимодействовать с устройством.

Так вот, Selenium WebDriver, или просто WebDriver – это драйвер браузера, то есть не имеющая пользовательского интерфейса программная библиотека, которая позволяет различным другим программам взаимодействовать с браузером, управлять его поведением, получать от браузера какие-то данные и заставлять браузер выполнять какие-то команды.

Исходя из этого определения, ясно, что WebDriver не имеет прямого отношения к тестированию. Он всего лишь предоставляет автотестам доступ к браузеру. На этом его функции заканчиваются.

Впрочем, в рамках проекта Selenium разрабатывается не только драйвер, но ещё несколько сопутствующих продуктов – Selenium Server позволяет организовать удалённый запуск браузера, при помощи Selenium Grid можно построить кластер из Selenium-серверов. Они встают в один ряд с вышеперечисленными инструментами и фреймворками, потому что также участвуют в построении системы запуска тестов. Кроме того, имеется «рекордер», который называется Selenium IDE, он умеет записывать действия пользователя и генерировать код, в котором используется интерфейс WebDriver для выполнения записанных действий.

Но главным в проекте Selenium является именно WebDriver, это ключевой элемент экосистемы Selenium.

Существуют ли другие драйверы? Разумеется.

Внутри каждого коммерческого «интегрированного» инструмента имеются драйверы браузеров, но они как правило не могут быть использованы отдельно вне этого инструмента. Есть и бесплатные открытые драйверы – Watir предоставляет доступ к основным браузерам, WatiN имеет неплохой драйвер для браузера Internet Explorer, Sahi умеет работать с «большой пятёркой» браузеров.

Как сравнить Selenium WebDriver с другими инструментами?

Из всего вышенаписанного можно сделать вывод, что сравнивать WebDriver с каким-нибудь инструментом тестирования типа TestComplete или Sahi бессмысленно. Они находятся в разных весовых категориях. Это всё равно, что сравнивать драйвер принтера с текстовым редактором.

А что можно сравнивать?

Что касается сравнения с «комплексным» инструментами типа TestComplete или Sahi, для этого нужно брать не WebDriver, а полный стек.

Например, стек для технологии Java может быть таким: Jenkins + Maven + Thucydices + JUnit+ WebDriver. К этому добавляются ещё все возможности языка программирования Java, плюс масса плагинов для Maven и Jenkins, а чтобы совсем всё было круто – можно запускать тесты в облаках, используя какой-нибудь сервис типа SauceLabs.

Вот тогда сравнение будет интересным. Но это уже заслуга не только WebDriver, важен весь стек, а не только драйвер браузера. Что касается WebDriver, стоит отметить лишь то, что он прекрасно встраивается практически в любой стек, это одно из его достоинств как «независимого» драйвера.

Разумеется, WebDriver может использоваться не только при тестировании. Ему вообще безразлично, кто и зачем хочет управлять браузером. Вы можете автоматизировать какие-то рутинные задачи. Можете сделать ботов, которые будут флудить в форумах. Можете сделать скрипт, который автоматически снимает скриншоты для документации. Всё что угодно. Драйверу всё равно. Он всего лишь предоставляет доступ к браузеру.

Кроме того, какой бы инструмент вы ни использовали – вполне возможно, что к нему удастся подключить WebDriver, который имеет реализации на самых разных языках – Java, C#, Ruby, Python. И тогда вы в дополнение ко всем возможностям вашего любимого инструмента добавите все достоинства WebDriver. Это стоит потраченных усилий, потому что среди драйверов на данный момент он лучший.

Ну да, я уже несколько раз повторил, что «он лучший», но при этом не привёл сравнения с другими драйверами. И не буду. Потому что есть аргумент, который в перспективе важнее любых сравнений.

Selenium WebDriver – это спецификация интерфейса для управления браузером

Самое главное отличие WebDriver от всех остальных драйверов заключается в том, что это «стандартный» драйвер, а все остальные – «нестандартные».

И это не простая фигура речи.

Организация W3C действительно приняла WebDriver за основу при разработке стандарта интерфейса для управления браузером. Сейчас он находится в состоянии публичного рассмотрения.

Через год-полтора этот стандарт будет утверждён. И тогда реализация интерфейса WebDriver будет возложена на производителей браузеров, а WebDriver как независимый драйвер, возможно, в будущем исчезнет совсем, потому что он будет встроен непосредственно в браузеры.

Таким образом, можно сказать, что Selenium WebDriver это вообще не инструмент, а спецификация, документ, стандарт, описывающий, какой интерфейс браузеры должны предоставлять наружу, чтобы через этот интерфейс можно было браузером управлять.

Пока стандарт обсуждается, производители браузеров уже действуют. В рамках проекта Selenium было разработано несколько референсных реализаций для различных браузеров, но постепенно эта деятельность переходит в ведение производителей браузеров. Драйвер для браузера Chrome разрабатывается в рамках проекта Chromium, его делает та же команда, которая занимается разработкой самого браузера. Драйвер для браузера Opera разрабатывается в компании Opera Software. Драйвер для браузера Firefox пока разрабатывается участниками проекта Selenium, но в недрах компании Mozilla уже готовится ему замена, которая носит кодовое название Marionette. Этот новый драйвер для Firefox уже доступен в девелоперских сборках браузера. На очереди Internet Explorer и Safari, к их разработке сотрудники соответствующих компаний пока не подключились, но кое-какие сдвиги в этом направлении есть, потому что стандарт (даже будущий) обязывает.

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

А что случится после того, как во всех браузерах будет реализован этот стандарт?

Было бы логично ожидать, что производители инструментов тестирования не станут изобретать велосипеды, а будут управлять браузером через стандартный интерфейс. Можно сказать, что все инструменты станут использовать WebDriver для взаимодействия с браузером. Но это будет уже не Selenium WebDriver как независимый драйвер, а Selenium WebDriver как спецификация интерфейса.

Так почему же у него такой примитивный интерфейс?

Набор команд последовательно сокращался, были выброшены такие «повышающие удобство использования» команды как check, uncheck (для чекбоксов), select (для выпадающих списков). Все они сводятся к более простой команде click и поэтому они лишние. Сейчас в интерфейсе WebDriver осталась только одна избыточная команда – это submit, но может быть когда-нибудь и она будет устранена.

Кроме того, структура интерфейса проектировалась таким образом, чтобы можно было описать его на языке IDL (именно это сделано в стандарте W3C) и сделать реализации на различных языках программирования. Поэтому использовался минимум языковых идиом, минимум «скрытых» переменных, интерфейс «тупой и прямолинейный».

Но зато благодаря этой примитивности интерфейса сейчас для интерфейса WebDriver имеются реализации клиентских библиотек на Java, C#, Ruby, Python, JavaScript, PHP, Perl и даже Haskell!

И благодаря той же самой простоте WebDriver прекрасно интегрируется с любыми другими инструментами, встраивается в любой стек. В этом секрет его популярности и быстрого распространения – он не пытается «победить» другие инструменты, вместо этого он интегрируется с ними.

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

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

Постепенно появляются библиотеки, которые строятся на базе Selenium WebDriver и предоставляют более высокий уровень абстракции: Selenide, fluent-selenium, watir-webdriver, Thucidides. Популярные фреймворки для проектирования тестов позволяют наряду с другими драйверами использовать WebDriver. Среди таких фреймворков можно упомянуть Robot Framework, Capybara и тот же Thucidides.

Рано или поздно должны появиться вспомогательные библиотеки, облегчающие работу с теми или иными наборами виджетов – jQuery, Prototype, ExtJS, GWT и прочими.

Число таких расширений и инструментов будет расти, сложность тоже. Так что вскоре может так случиться, что вы, используя какой-то инструмент, будете выполнять тесты, даже не подозревая о том, что взаимодействие с браузером осуществляется через драйвер Selenium WebDriver.

Стоит ли тогда вообще изучать Selenium?

Может быть лучше изучать эти библиотеки и инструменты более высокого уровня?

Надеюсь, всё вышесказанное позволит вам лучше понять, какое место Selenium WebDriver занимает в общей картине мира и как он соотносится с другими инструментами. Если всё ещё остались непонятные моменты – задавайте вопросы в комментариях, я постараюсь всё прояснить.

Источник