Наши партнеры

UnixForum





Библиотека сайта rus-linux.net

Проект Selenium WebDriver


Автор:Simon Stewart
Перевод: Н.Ромоданов

16.9. Оглядываясь назад

Создание фреймворка автоматизации браузера во многом похоже на рисование комнаты; на первый взгляд, это выглядит как нечто, что должно делаться довольно легко. Все, что требуется сделать - это несколько слоев краски и работа выполнена. Проблема в том, что чем ближе вы подходите, тем больше появляются задач и деталей и тем дольше будет выполнение задачи. Что касается комнаты, это что-то вроде рисования ламп и светильников, радиаторов и плинтусов, на что начинает тратиться время. Что касается автоматизации браузеров, то это те все особенности и различия в возможностях браузеров, которые делают ситуацию еще более сложной. Самим резким образом на это отреагировал Даниэль Вагнер-Холл (Daniel Wagner-Hall), когда он, сидя рядом со мной и работая над драйвером Chrome, ударил руками по столу и в отчаянии пробормотал: «Все это - крайние случаи!». Было бы хорошо, если бы можно было вернуться в прошлое и сообщить самому себе о том, что проект займет намного больше времени, чем я ожидал.

Я также не могу не спросить, чтобы бы было с проектом, если бы мы определялись и делали только то, что необходимо в слое, например, атомы автоматизации ранее, чем мы это сделали. Конечно, были бы решены некоторые из проблем, с которыми столкнулся проект, касающихся внутренних и внешних, технических и социальных аспектов. Core и RC были реализованы для ограниченного набора языков, по сути только для Javascript и Java. Джейсон Хаггинс Huggins (Jason Huggins) говорил об этом как об уровне «осваиваемости», присутствующим в Selenium, который делает проект легким для тех, кто принимает в нем участие. Этот уровень «осваиваемости» стал везде доступным в WebDriver только благодаря атомам. А что касается последнего — причина, по которой стало возможным так широко использовать атомы в том, что компилятор Closure Compiler, который мы стали использовать почти сразу, был выпущен как проект с открытым кодом.

Также интересно поразмышлять о том, что мы сделали правильно. Я все еще считаю, что написать то, что с точки зрения пользователя, выглядит как фреймворк, является правильным решение. Сначала это окупилось тем, что сразу были найдены места, где потребовались улучшения, и это быстро увеличило отдачу от инструментального средства. Позже, когда драйвер WebDriver стал справляться с более крупными и сложными задачами, а число разработчиков, его использующих, увеличилось, это значило, что новые интерфейсы API нужно было добавлять аккуратно и внимательно, строго сохраняя целенаправленность проекта. Учитывая масштабы того, что мы пытаемся сделать, эта целенаправленность является жизненно важной.

Жесткая привязка к браузеру является в некотором смысле одновременно как правильной, так и неправильной. Она правильная, поскольку позволила нам с особой точностью имитировать поведение пользователей и очень хорошо управлять браузером. Она неправильная, поскольку такой подход является технически чрезвычайно сложным, особенно когда в браузере для подключения нужно найти нужный механизм. Действующим примером является постоянная эволюция драйвера IE и, хотя этого мы здесь не рассматривали, то же самое можно сказать и о драйвере Chrome, который имеет свою долгую и интересную историю. В какой-то момент нам потребовалось найти способ справиться с этой сложностью.

16.10. Заглядывая в будущее

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

Одной из первоначальных задач было использование WebDriver в качестве строительного модуля для других интерфейсов API и инструментальных средств. Конечно, Selenium разрабатывается не в вакууме: есть много других средств для автоматизации браузеров, имеющий открытый исходный код. Одним из них является Watir (Web Application Testing In Ruby — тестирование веб приложений в языке Ruby), и была начата работа, представляющая собой совместные усилия разработчиков Selenium и Watir по использованию интерфейса Watir API поверх WebDriver. Мы также заинтересованы в работе с другими проектами, поскольку успешное управление всеми браузерами - это тяжелый труд. Было бы неплохо иметь твердую основу, на которую могли бы опираться другие. Мы надеемся, что этой основой является WebDriver.

Представление о будущем проекта было показано компанией Opera Software, которая самостоятельно реализовала интерфес WebDriver API, использующий набор тестов WebDriver для проверки работы своего собственного кода, и которая будет выпускать свой собственный драйвер OperaDriver. Разработчики Selenium также работают с разработчиками Chromium над вопросами добавления лучших механизмов подключения к этому браузеру и вопросами поддержки WebDriver для этого браузера, в том числе и с помощью расширений Chrome. У нас дружеские отношения с компанией Mozilla, которая предоставила свой код для драйвера FirefoxDriver, и с разработчиков популярного эмулятора браузеров HtmlUnit, используемого с языком Java.

Взгляд в будущее показывает, что эта тенденция продолжится — механизмы подключения, используемые для автоматизации, преобразуются во многих различных браузерах к единообразному виду. Ясно, что это преимущество для тех, кто занимается написанием тестов для веб-приложений, и также очевидно, что это преимущество для разработчиков браузеров. Например, из-за сравнительно дорого тестирования вручную, во многих крупных проектах в значительной степени полагаются на автоматизированное тестирование. Если оно невозможно, или даже если оно используется «всего лишь» тестирования с конкретным браузером, то тесты, не прошедшие с ним, показывают общую картину, насколько хорошо с этим браузером работают. сложные приложения Вопрос о то, будут ли эти механизмы автоматизации основываться на использовании WebDriver, остается открытым, но мы можем надеяться!

Ближайшие несколько лет будут очень интересными. Поскольку мы - проект с открытым кодом, мы приглашаем вас присоединиться к нам в нашем турне на станице http://selenium.googlecode.com/.

Примечания

  1. http://fit.c2.com
  2. Это очень похоже на проект FIT, и Джеймс Шор (James Shore), один из его координаторов, помог на странице http://jamesshore.com/Blog/The-Problems-With-Acceptance-Testing.html разобраться с некоторыми его недостатками
  3. Например, сервер, работающий дистанционно, каждый раз, когда возникает исключение, возвращает копию экрана в кодировке base64 в качестве дополнительного средства отладки, а драйвер Firefox этого не делает
  4. Т.е. всегда возвращает один и тот же результат.

Creative Commons

Перевод был сделан в соответствии с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.

К началу статьи.