что такое selenium в тестировании
Селениум: тестирование веб-приложений и другие полезные функции
Selenium — это не одиночный инструмент, как многие считают по ошибке. Селениум — это целый набор разношерстного инструментария, который решает задачи разного уровня по тестированию. Поэтому если говорить о Селениуме, то нужно коснуться всего набора инструментов.
Селениум: набор инструментов
Selenium IDE — это специализированный плагин для FireFox, который дает тестировщикам возможность проводить запись своих действий для будущего анализа. Он способен разработать тестовые случаи, но только в «Огненной Лисе», так как другие браузеры он не поддерживает. При этом записанные сценарии тестирования можно конвертировать в другие языки программирования, чтобы выполнить их в других браузерах. Это простой в использовании плагин. Он не требует для тестирования глубоких знаний языков программирования, так как способен сам остоятельно сформировать нужный код.
Selenium RC — это полноценная среда для тестирования, которая дает возможность применять популярные языки программирования: Java, C#, PHP, Python, Ruby, PERL и другие. Данная среда уже практически не применяется и не рекомендуется для использования.
Selenium WebDriver — это среда для тестирования, которая пришла заменить Selenium RC. По сути, WebDriver — это несколько специальных библиотек для разных языков программирования, которые можно применять для написания программ для управления браузером. Это свободный набор библиотек, поэтому их можно использовать в разных браузерах. Selenium WebDriver позволяет создать собственный фреймворк для тестирования.
Selenium Grid — это крутой инструмент, который позволяет одновременно запускать по несколько тестов на разных устройствах или разных браузерах, что ускоряет сам процесс тестирования.
Особенности инструментов Селениум
Каждый из существующих на рынке инструментов имеет свои особенности, что отличает один инструмент от другого. Набор инструментов Селениум имеет свои особенности:
Открытый исходный код.
Расширяет свои возможности при подключении дополнительных технологий.
Работает с разными браузерами.
Работает с разными операционными системами.
Функционирует на мобильных устройствах.
Проводит тестирования прямо в браузере.
Можно проводить тестирования на разных устройствах одновременно, применяя Selenium Grid.
Недостатки набора инструментов Селениум
У Селениум есть свои недостатки:
Тестирует только веб-приложения.
Отсутствуют сценарии восстановления и хранилище объектов.
Нет полноценной IDE.
Не дает возможность контролировать элементы управления в браузере.
По умолчанию не генерирует отчеты о тестировании.
Заключение
Селениум идеально подойдет для тех, кто уже устал все тестировать «руками», потому что Selenium — это эффективный набор инструментов для автоматизации тестирования.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Сказ о 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 — отечественной разработке для решения задач по тестированию и обеспечению качества ПО.
Что такое 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 занимает в общей картине мира и как он соотносится с другими инструментами. Если всё ещё остались непонятные моменты – задавайте вопросы в комментариях, я постараюсь всё прояснить.