что такое selenium в тестировании
Selenium
Selenium — это набор программ с открытым исходным кодом, которые применяют для тестирования веб-приложений и администрирования сайтов локально и в сети. Программы Selenium позволяют автоматизировать действия браузера. Среди программ проекта:
Selenium IDE
Selenium IDE — плагин для браузера Firefoх для записи действий пользователя (тестировщика) и их воспроизведения для тестирования. Является библиотекой Selenium с графическим интерфейсом и возможностями для работы со сценариями тестирования веб-страниц. IDE генерирует код для Selenium RC или Selenium WebDriver, который повторяет записанные действия пользователей.
Selenium RC
Selenium RC (Remote Control) — предыдущий основной продукт Selenium до появления WebDriver в 2007 году. Программа, называемая также Selenium 1.0, являлась средством удаленного управления браузером, но по функциональности сильно уступала WebDriver (Selenium 2.0). Selenium RC продолжает поставляться в дистрибутиве WebDriver, но продукт не развивается — при необходимости сложных тестов вне ограничений первой версии пользователям предлагают воспользоваться второй.
Selenium WebDriver
WebDriver напрямую отправляет команды браузеру, используя его API и получает результаты тестирования. В предыдущей версии Selenium RC принцип работы был другим — программа внедряла код на языке JavaScript в браузер для управления им. WebDriver же использует способ взаимодействия с браузером, максимально близкий к действиям обычного пользователя.
Тестировщик ПО на Java
Освойте ручное и автоматизированное тестирование и получите IT-профессию, даже не имея технического образования. Дополнительная скидка 5% по промокоду BLOG.
Selenium Grid
Selenium Grid — кластер из нескольких Selenium-серверов, которые позволяют управлять браузером удаленно по сети. Grid позволяет организовать сеть, в которой можно запускать большое количество браузеров на большом количестве компьютеров. Параллельное тестирование позволяет тестировщикам экономить время.
Преимущества Selenium
Selenium — бесплатный продукт с открытым исходным кодом для тестирования с поддержкой всех основных языков программирования. Его можно использовать на разных браузерах в разных операционных системах, включая мобильные устройства.
Selenium WebDriver — гибкий инструмент тестирования, который можно легко интегрировать с разными тестовыми фреймворками и другими инструментами тестирования. Это позволяет расширить инструментарий тестировщика и применять его для узких задач, например web crawling и тестирования производительности.
Selenium разрабатывают с 2004 года, и за это время он стал самым популярным инструментом функционального тестирования веб-приложений. Его используют в крупных корпорациях, включая Google.
Недостатки Selenium
В программах Selenium можно тестировать только веб-приложения, функций тестирования сетевых и десктопных приложений в комплекте нет. Также для работы с Selenium нужно владеть продвинутыми навыками программирования и написания скриптов. Новички в тестировании могут пользоваться более простыми аналогами Selenium, например Katalon Studio или UFT.
Быстрый вход в IT без технического образования — за 4 месяца вы на практике поймете основы веб-разработки, научитесь работать с баг-трекерами, тестировать приложения и API, составлять SQl-запросы.
Сказ о Selenium тестировании
Когда перед вашей командой стоит задача написать действительно крупный проект, всегда становится задача тестировать написанный код. Если сервер тестировать относительно легко, то JS код чаще всего тестировать просто невозможно в связи с его природой.
Природу JS решила обойти отличная команда разработчиков, которая создала уникальный в своем роде продукт, который позволяет написать приемочные тесты, которые будут взаимодействовать на прямую с браузером. У них получилось очень и очень круто, но грабли были, есть и будут. По этому я расскажу о граблях, которые обычно встречаю во время работы с данным прекрасным продуктом.
Данная статья больше ориентирована на новичков, чем на профессионалов.
Архитектура тестов
Часто встает вопрос, как спроектировать тесты, чтоб сократить написание кода и не заниматься копипастом. Обычно используются generic файлы, которые наследуют unitTest класс вашего языка. У нас всегда есть возможность изменить поведение для какой-то группы тестов, не затрагивая другие группы. К примеру:
Когда вы отделяете функционал по категориям, выносите его в директории, а в каждой директории создавайте свой generic. Каждый тест должен наследовать класс generic с которым он лежит в директории. Generic может быть даже пустым, в будущем он пригодится, даю гарантию.
Запуск тестов
Разница между юнит тестами и приемочными тестами заключается, что в unittest обычно тестируют алгоритмы и логику, а приемочные уже тестируют саму систему, с реальными данными, которые получают из работающей БД.
База данных
Задача всех тестов, быть изолированными друг от друга. А значит на каждый запуск теста, нужно создавать новую тестовую БД. У каждого unittest функционала языка есть метод setUp, который вызывается перед запуском теста. Попробуйте в нем изменить настройки до иницилизации базы данных. Так вы сможете полностью изолироваться от других тестов и существующих данных, а если вы еще используете механизмы кэширования, очистите кэш или воспользуйтесь пустым хранилищем кэша как и с БД.
Фикстуры
По сути, это данные которые будут записаны в вашу тестовую БД, для того чтоб браузер открыл сайт и не получил ошибок. Базовые данные стоит записать в setUp методе главного generic`a. А остальные записывать по мере потребностей данных в самих тестах.
Сохранение данных базы
Создайте путь для возможного дебага, часто бывает так, что тесты по не понятной причине глохнут с ошибкой, часто бывает что нужно сохранить базу и оставить браузер в живых. Возможно вам и sleep подойдет? Если вы сделали функционал сохранения базы, сделайте так-же функционал очистки старых баз. У меня к примеру mongoDB смог за неделю разработки создать 80гб баз данных.
Передача подключения
Когда открывается браузер, запомните, он никак не связан с вашим тестом. Если селениум просто откроет браузер и начнет выполнять операции, скорее всего он будет выполнять их над существующим проектом. Передайте в браузер параметры, которые помогут идентифицировать нужную тестовую базу. В свое время, браузер должен будет передать информацию на сервер.
Кодовая база
Вот тут вам нужно будет сесть и подумать, как сделать для самого себя жизнь прекрасней.
К примеру, у вас асинхронное многопользовательское real time приложение(игра), нужно писать тесты где могут взаимодействовать два и более пользователей. Посмотрите, будет ли вам удобно переключатся между окнами браузера с помощью драйвера? Нет, напишите свою простую реализацию.
Нужно собственные assert`ы? К примеру проверить существование элемента в дереве?
Вполне вероятно, что у вашего проекта есть свои особенности и нужно подготовить некоторую функциоальную часть тестов для этого.
Таймауты
Всегда при тестировании, нам нужно будет выполнять таймауты. Толи это будет загрузка страницы, ajax или socket запрос на сервер. С загрузкой страницы драйвера содержат встроенный метод для ожидания. Но вот с ajax и socket запросами всё сложнее. Вам нужно будет написать счетчик отправленных запросов и полученных ответов. Когда вы отправляем запрос, счетчик инкрементится, когда приходит ответ, декрементится. В самом generic`e реализовываем метод, который будет проверять данный счетчик и если он не равен 0, то пусть ждет, но ограничивайте ожидание, ответ от сервера может и не прийти.
Взаимодействие кода тестов и браузера.
Порой нам нужно будет получать состояния или какие-то данные, для проверки их значений с ожидаемыми. Сразу напишите пути получения этих данных. К примеру если вы используете AngularJS, то чтоб получить доступ к данным сервиса, напишите прослойку для этого.
Если нету какой-то возможности с помощью тестов эмулировать действия пользователя, то нужно вызывать обработчики этих событий. Дайте возможность тестам стучаться к исполняемому JS коду.
Разные среды исполнения
Чаще всего получается так, что тест работает у вас на компе, но не работает у других. Это может быть связано с ОС, версией селениума, разрешением монитора и вплоть до версий браузера. Советую, заведите себе дешевый VPS, на котором вы сможете запускать тесты. На серверной линухе можно запускать тесты прямо из браузера. К примеру ман, который мне помог www.alittlemadness.com/2008/03/05/running-selenium-headless В добавок, вы сэкономите свое время, пока будете ожидать завершения тестов. Не забудьте, браузер весьма требовательный по оперативке, добавьте хороший запас swap.
Баги драйверов и самого селениума
Первое, посетите code.google.com/p/selenium/issues/list и пробегитесь глазами по багам.
Второе, если вы уверены, что это обязано работать, пройдитесь JS дебагом по коду. Вполне вероятно что вы найдете место, которое бажит по вине самого селениума или драйвера. К примеру я наткнулся на баг, когда при mouse move, chomedriver не передает событие which, которе отвечает за текущую нажатую кнопку мыши.
Так-же известная неприятность, которая связа со скролами. Селениум ничего не умеет скролить кроме скролла у body. Решения два. Писать функцию скролла или на сервере ставить большое разрешение виртуального монитора.
Часто тесты могут глючить из-за таймаутов. Воспользуйтесь функционалом, который сможет повторят тесты. Дайте ему возможность на сервере перезапускать тест раза 3. Если тест валится, значит он не рабочий, если он валится периодически, проблемы в таймаутах, которые не заметны пользователю, но заметны самому селениуму.
Кросс-браузерное тестирование в Selenium
В этой статье мы рассмотрим кросс-браузерное тестирование. Это тип тестирования, который проверяет, работает ли приложение так, как ожидается, в нескольких браузерах, операционных системах и устройствах. Мы можем проводить кросс-браузерное тестирование с помощью автоматизации и без нее. Сценарии автоматизированного тестирования могут быть написаны или созданы с помощью таких программ, как TestProject и Selenium.
Примечание: Код из этой статьи находится на GitHub здесь.
Что такое кросс-браузерное тестирование?
Кросс-браузерное тестирование гарантирует, что наше тестируемое приложение (AUT) совместимо с каждым браузером, операционной системой и устройством. Цель заключается в сравнении ожидаемого поведения приложения в различных случаях. Бывают случаи, когда один и тот же тестовый сценарий проходит на одном или нескольких экземплярах, но не работает на другом экземпляре.
Возможно, сбой произошел из-за нашего тестового скрипта или приложения. Вы когда-нибудь пытались открыть веб-сайт с помощью Internet Explorer, но он не работал, а затем тот же сайт без проблем открывался в Chrome? Такие проблемы выявляются во время кросс-браузерного тестирования, поскольку данные из AUT отображаются по-разному в каждом браузере.
Преимущества кросс-браузерного тестирования
Я сосредоточусь на двух преимуществах кросс-браузерного тестирования:
Время
Создание и выполнение индивидуального сценария тестирования (Test Script) для уникальных сценариев занимает много времени. Поэтому наши тестовые сценарии создаются с тестовыми данными для использования их комбинаций. Один и тот же сценарий тестирования может выполняться на Chrome и Windows для первой итерации, затем на Firefox и Mac для второй итерации, а затем на других сценариях для последующих итераций.
Тестовое покрытие
Что будет включено в наши сценарии тестирования, зависит от требований.
То, сколько охвачено в наших сценариях тестирования, зависит от браузеров и их различных версий.
Тестовое покрытие является эффективным мерилом для процесса тестирования. Однако 100% покрытие трудно обеспечить, и, скорее всего, функция ведет себя не так, как это обычно происходит в конкретной версии.
Как осуществить кросс-браузерное тестирование в Selenium?
Мы осуществляем кросс-браузерное тестирование в Selenium, используя его сетку (grid) или тестовые данные. Selenium Grid упрощает процесс, а тестовые данные используются в качестве исходных. С помощью Selenium Grid наши тестовые сценарии выполняются параллельно на нескольких удаленных устройствах. Команды отправляются клиентом удаленным экземплярам браузера.
Тестовые данные могут храниться в файле Excel, CSV, файле свойств, XML или базе данных. Мы также можем объединить TestNG с тестовыми данными для проведения тестирования на основе данных или кросс-браузерного тестирования. Для тестирования на основе данных аннотация DataProvider и атрибут dataProvider или атрибут dataProviderClass позволяют нашему тестовому сценарию получать неограниченное количество значений.
Когда речь идет о кросс-браузерном тестировании, мы можем использовать тег параметра и аннотацию Parameters для передачи различных имен браузеров. Ниже приведены фрагменты кода, отображающие XML-файл с тегом параметра и тестовый сценарий с аннотацией Parameters.
В XML-файле тег параметра расположен на уровне теста. У нас есть возможность разместить тег на уровне тестового набора, на уровне теста или на обоих уровнях. Обратите внимание, что тег параметра имеет имя и значение с данными между двойными кавычками. Его имя, т.е. «BrowserType», передается тестовому сценарию через аннотацию @Parameters, а значение, т.е. «Chrome», передается в операторы if и else if.
Операторы if и else if устанавливают Chrome, Edge или Firefox. Каждый браузер получал команды от одного и того же тестового сценария после выполнения из XML-файла. Следующие результаты тестирования показывают, как успешно загружается страница TestProject, а консоль печатает уникальное имя браузера и заголовок страницы.
Кросс-браузерное тестирование в Selenium с помощью TestProject
OpenSDK / Закодированный тест
Существует 2 способа проведения кросс-браузерного тестирования с помощью TestProject. Мы можем использовать OpenSDK с открытым исходным кодом или AI-Powered Test Recorder. OpenSDK оборачивается в Selenium и поддерживает Java, C# или Python. Наши тестовые сценарии похожи на кросс-браузерное тестирование в Selenium с минимальными изменениями в коде и зависимостях. Мы должны включить зависимость TestProject для Maven или Gradle, импортировать драйверы браузера и передать токен.
AI-Powered Test Recorder
С помощью AI-Powered Test Recorder мы создаем новое веб-задание, затем выбираем несколько браузеров, таких как Chrome, Edge и Firefox. Тест в задании TestProject позволяет нам выбрать дополнительный источник данных CSV, если мы хотим выполнить тестирование на основе данных. Вот несколько скриншотов, показывающих шаги по выполнению кросс-браузерного тестирования и отчета.
Вот пошаговая демонстрация кросс-браузерного тестирования с помощью TestProject AI-Powered Test Recorder.
Выводы
Кросс-браузерное тестирование осуществляется с помощью Selenium и TestProject.
TestProject позволяет нам создавать собственные тестовые сценарии с использованием Java, C# или Python после добавления OpenSDK с открытым исходным кодом. OpenSDK является оберткой Selenium, поэтому он содержит команды Selenium плюс дополнительные команды из TestProject. Кроме того, мы можем использовать TestProject’s AI-Powered Test Recorder для проведения кросс-браузерного тестирования. Это удобный процесс, который требует от нас только выбора браузера, который мы хотим использовать для кросс-браузерного тестирования.
Перевод статьи подготовлен в рамках курса «Java QA Engineer. Basic». Всех желающих приглашаем на двухдневный онлайн-интенсив «Теория тестирования и практика в системах TestIT и Jira». На интенсиве мы узнаем, что такое тестирование и откуда оно появилось, кто такой тестировщик и что он делает. Изучим модели разработки ПО, жизненный цикл тестирования, чек листы и тест-кейсы, а также дефекты. На втором занятии познакомимся с одним из главных трекеров задач и дефектов — Jira, а также попрактикуемся в TestIT — отечественной разработке для решения задач по тестированию и обеспечению качества ПО.
DevPoint: Selenium в тестировании веб-приложений
С такими ситуациями очень часто сталкивался и меня это не устраивало. При поиске подходящего метода/инструмента тестирования я наткнулся на Selenium. И применяю его уже более 3-х лет.
В Киеве 9-го апреля прошла конференция DevPoint, посвященная web — разработке. Организатором данного мероприятия была компания Uniweb. В рамках ее, решил поделиться впечатлением про Selenium.
Selenium состоит из множества подпроектов, но выделить хотел только три:
Selenium Core — JavaScript Framework для написание и выполнения тестов. Используется в Selenium IDE и Remote Control*.
Selenium IDE — плагин для Firefox, который позволяет записывать и воспроизводить тесты. Также может генерировать код тестов для использования в Selenium Remote Control.
Selenium Remote Control — клиент-серверная система, которая позволяет Вам управлять веб-браузерами локально, или на других компьютерах, используя практически любой язык программирования
В рамках этого доклада про Selenium Core не было времени акцентировать внимание, хотя этот проект наиболее интересен для написания тестов с нетривиальной логикой.
Selenium IDE
Применяем Selenium IDE на практике
Для примера взял живой старый проект, который покрыть тестами задача еще та. Это обычный интернет-магазин, который используется для внутренних оптовых закупок в одной компании, имен не называем…
Первый тест, который мы напишем будет просто авторизоваться в системе:
И последних два теста, которые покрывают логику создания и редактирования заказа:
И для проверки наших тестов было намерено испорчено сохранение заказа:
Selenium Remote Control
Selenium Remote Control — это http демон, который принимает команды через GET и выполняет их. API по общению с Selenium RC есть почти под все языки программирования. В данном докладе речь идет только про API для PHP, которое предоставляется c PHPUnit
Как уже говорилось ранние в Selenium IDE есть приятная опция по генерированию кода для *Unit:
Таким образом вы можете просто копировать код и выполнять его в своих PHPUnit suite.
Также в PHPUnit — Selenium есть возможность запускать тесты написанные в Selenium IDE:
Без напильника не обойтись…
Для решения проблемы с выполнением команд wait* нужно рассмотреть как они выполняются в PHPUnit:
Фактически мы зацикливаем выполнение команды, на определенный интервал и ждем пока наше условие не станет true. Реализация PHPUnit — Selenium посылая команду Selenium RC ждет от нее только два ответа, что все хорошо или что все плохо. Если пришел ответ ERROR, то он сразу закрывает браузер, пишет что произошла ошибка и соответственно наш цикл будет слать команды в уже закрытую сессию Selenium RC.
Код с решением этих проблем я выложил на github и не буду на нем останавливаться.
Еще из приятных вещей в Selenium RC то, что он умеет делать скриншоты при обнаружении ошибки:
Минус в том, что на скриншотах не подсвечивается место возникновения ошибки, но по тексту в PHPUnit обычно легко понять что не так.
Дергаем за ниточки не FireFox
Что такое 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 занимает в общей картине мира и как он соотносится с другими инструментами. Если всё ещё остались непонятные моменты – задавайте вопросы в комментариях, я постараюсь всё прояснить.