Немного истории
Если проанализировать историю выпуска релизов Selenium, можно заметить, что почти всегда появление нового релиза было связано с выходом новой версии браузера Firefox.
Причина в том, что драйвер для Firefox был реализован как дополнение (add-on) к браузеру. Selenium при запуске браузера автоматически “втыкал” в него это дополнение и через него происходило всё дальнейшее взаимодействие между Selenium и браузером.
Выход новой версии Firefox часто приводил к тому, что дополнение переставало работать. То какой-нибудь интерфейс у браузера поменяется, то новая политика безопасности появится, то баги в браузере мешают и приходится придумывать для них обходной путь. В общем, как только обновляется Firefox – надо делать новую версию дополнения.
Для простоты развёртывания когда-то давно было решено включить это дополнение прямо внутрь клиентских библиотек. Java-разработчик подключает зависимость от пакета, который лежит в Maven-репозитории и пользуется – а драйвер уже сидит там внутри. Или C#-разработчик устанавливает пакет из NuGet-репозитория. Или Python-разрабочик из pypi-репозитория. Один пакет, ничего лишнего.
Увы, эта простота аукнулась в другом месте. Выходит новая версия Firefox, следом появляется новая версия Selenium – и после этого пользователям надо обновлять все клиентские библиотеки для всех используемых языков программирования и все узлы Selenium Grid. Неприятно…
В такую же ловушку когда-то попал и драйвер для браузера Internet Explorer, только там вместо дополнения была dll-ка, которая тоже включалась внутрь дистрибутива Selenium и отдельно её обновить было невозможно. А ломалась она тоже весьма часто.
Выходом стало создание отдельного исполняемого файла, который служит посредником при взаимодействии с браузером, и который можно устанавливать и обновлять отдельно и независимо от клиентских библиотек.
Выходит новая версия браузера, вместе с ней выходит новая версия драйвера-посредника, его надо обновить – но зато узлы Selenium Grid и клиентские библиотеки обновлять не нужно. Количество работы по поддержке инфраструктуры резко сокращается.
Ещё один плюс такой схемы заключается в том, что разработку такого посредника можно “спихнуть” на производителя браузера. Пусть он там использует всякие недокументированные возможности, пусть даже код не открывает, если не хочет – лишь бы работало в соответствии со стандартом.
Сначала такая схема была успешно опробована на браузере Google Chrome. Потом на браузере Microsoft Edge.
И вот наконец дошло дело и до браузера Firefox.
Теперь для него тоже есть вспомогательный исполняемый файл.
Он называется geckodriver (браузер Firefox построен на движке Gecko, отсюда и название).
А старый драйвер в новых версиях браузера больше не работает. Такие дела…
Краткие выводы
Чтобы запускать тесты в Firefox версии 48 или новее нужно:
- загрузить geckodriver для вашей платформы и поместить его в PATH,
- использовать версию Selenium 3.0, которая пока имеет статус beta, то есть может быть не очень стабильна, но кто не рискует тот
не пьёт шампанскоене может тестировать в новых версиях Firefox.
Возникают проблемы? Пишите баг-репорты.
А что случилось с Marionette?
Те, кто следит на новостями проекта Selenium, наверняка слышали, что Mozilla ещё с 2012 года работает над созданием новой технологии Marionette для удалённого управления браузером, которая должна прийти на смену FirefoxDriver.
С ней ничего не случилось, именно эта технология лежит в основе geckodriver.
Marionette – это название протокола и встроенного в браузер сервера для удалённой отладки. Это внутренний протокол, не совместимый со стандартом W3C WebDriver, хотя содержащий похожий набор операций (что неудивительно, ведь оба протокола предназачены для решения одной и той же задачи – управления браузером).
Geckodriver – это адаптер, преобразователь из протокола W3C WebDriver в протокол Marionette.
Набор возможностей Marionette шире, чем текущий набор возможностей WebDriver. Некоторые из них, наверное, появятся в следующей версии WebDriver 4, например, поддержка Shadow DOM. Впрочем, это уже совсем другая история.