Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Про Selenium и один «велосипед». Продолжение. part 2

Anna | 3.06.2014 | нет комментариев
Вводную дозволено прочитать тут.

5. Эксперимент.

image
Сам демо-план со каждой конструкцией был сделан по инструкции из этой статьи (метод для Eclipse, Jbehave образец).

— Что должно было получиться.

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

Все это должно быть:
— описано в виде BDD – сценариев;
— с одновременным применением вероятностей моего самодельного фреймворка и thucydides;
— должен быть использован репортинг thucydides.

Получилось следующее.

— Модель взаимодействия с приложением.

Преемники классов, описывающих страницы и их фрагменты.
image
AnyOneCPage. Так я решил испробовать наделить PageObject свойствами, которыми владеет моя вариация одноименного дизайн-паттерна. Я придумал несколько преемников этого класса, т.к. для данного приложения свойственно возникновение страниц с горизонтальными панелями кнопок, исполняющих разные действия, и вертикальными панелями ссылок на разные списки. Примеры этих преемников:

— для объектов, возникающих в отдельном окне браузера
image

— вариация примера выше — для объектов, у которых есть ссылки на связанные с ними списки
image

— основная страница вэб – заказчика 1С
image

Есть еще несколько других примеров. Но того, что описано выше – больше чем довольно. Обратите внимание на подчеркнутые ссылки. Все объекты, с которыми следует трудиться, ссылаются на одно и тоже, их функции дюже схожи.

Следственно в моем примере все применение класса PageObject сводится к дальнейшему:
— минимальное изложение функциональности всех объектов, с которыми дозволено трудиться в рамках вэб-заказчика продукта 1С (работа с панелями кнопок, списком ссылок);
— привязка частей, на которые эта страница будет «раскладываться», к определенному URL и предоставление пригодных функций объекта PageObject. Их получают в свое распоряжение элементы декомпозиции страницы (преемники FunctionalPart).

image
OneCFunctionalContainer как раз и необходим для того, Дабы описывать ту функциональность, которую предстоит «протестировать». Перед всяким исполняемым действием будет проверено – а на той ли странице мы находимся (а в друг позже наших действий «одинСка» нас перекинет в какой-нибудь хелп либо на сайт с порнушкой). Это модифицированный алгорифм переключения вкладок/фрэймов. Помимо того, сейчас «контейнер» может воспользоваться пригодными механизмами работы (заложенными разработчиками thucydides) с элементами страниц. Примеры 1 и 2.

image
Как думайте, много различий того, что в приведенном окне от того, что ниже?
image

Либо вот такие примеры:
1 и 2

Firebug мне сказал, что разница только в идентификаторах и комплекте (кстати, однородных) кнопок.
Таким образом, всю тестируемую функциональность я описал в преемниках класса FunctionalPart и один раз. А для тестов разница будет в том, как получить тот либо другой комплект элементов – с основной страницы либо из опять появившегося окна браузера:

page = (T) oneCInstance.getContentPage(contentClass, windowIndex);
page.getContent(Contractor.class).setCity(city)

либо так

mainPage.getByCaptionFromMainPage(Contractor.class, caption);

Последняя составляющая модели.
Класс Pages необходим для создания экземпляров PageObject. Entity в чем-то аналогичен. Я его наделил свойствами класса Pages, спрятав вовнутрь необходимый экземпляр, и создается данный экземпляр в момент создания экземпляра Entity (OneCApplication).

Я думаю, что дозволено было бы поступить и напротив. Правда, в этом случае тестируемое приложение (если не пытаться копнуть немножко вглубь) создавалось бы согласно правилам, заложенным в thucydides. Я же легко решил посвоевольничать и сократить потраченное время. Впрочем, альтернативное и правильное направление будет представлено дальше.

Выходит. У меня получилась некоторая модель, которая помогает описать тестируемое приложение и методы взаимодействия с ним. У меня есть фиксированный комплект «страниц» с некоторым базовым поведением, но переменным контентом (различные элементы, документы, отчеты и т.д.). Все имеющиеся страницы представлены фиксированным комплектом однородных классов. От их объектов я могу получать всякие изложения комплектов элементов, над которыми необходимо проводить определенные действия. Эти изложения дозволено раскладывать на больше примитивные. Либо скомпоновать примитивные изложения внутри одного трудного. Данный комплект может безгранично расширяться по мере выхода новых фич для проверки. Изложения элементов декомпозиции могут наследовать функциональность друг от друга.

Но здесь появляется вопрос. А как это дозволено применять для заявленной модели изложения тестов?

— Тесты

image
ScenarioSteps первоначально нет в JBehave. Это изобретение разработчиков thucydides. Я бы сказал, что это дюже пригодное изобретение, т.к. для больше широкого повторного применения того, что вызывает то либо иное проверяемое действие, необходимо было бы писать класс, скрывающий в себе Page Object’ы и манипулирующий ими.

Так предлагают нам трудиться авторы.

Мой же вариант несколько больше хардкорный, т.к. я крепко спешил. Принципиальная разница в том, что я создаю webdriver снаружи. В описанном разработчиками варианте он создается средствами thucydides (как бы изнутри). Мне было увлекательно принудить данный механизм трудиться напротив – открывать браузер по моим настройкам, скажем. О многом я не знал на момент создания этого примера, следственно, как минимум, его невозможно считать оптимальным. Но дозволено ознакомиться. А мысль о том, как же исполнять те же действия без любых костылей будет описана далеlqvmk!br/>
Thucydides может строить отчеты, детализированные по шагам с прикрепленными скриншотами, иллюстрирующими состояние в конце всякого шага. Правда, он может фотографировать всякое исполняемое действие.

Нужно сказать, что построение верно таких же отчетов при сделанном снаружи объекте webdriver’а – задача нетривиальная. Все потому, что фрэймворк им не управляет (не перезапускает, не закрывает). Экземпляр webdriver’a (а вернее – некоторый proxy — объект) создается согласно настройкам системных переменных машины, и перед запуском тестов создается типовой слушатель, тот, что скрывает его в себе и делает с него фотографии.

Но мой инструмент верно так же может фотографировать, у него есть логирование, в котором к сообщению лога может быть прикреплен файл (всякий, в том числе – прекрасное фото). Ниже модель решения.
image

Есть комплект механизмов, что поддерживают «прослушку» событий webdriver’а и отдельных окон браузера. При определенных настройках они делают фото, прикрепляемое к сообщениям лога. И есть механизм, тот, что читает сообщения и интерпретирует их по реализованному алгорифму. В thucydides есть средства «прослушки» шагов и сериализации итогов в отчет.

События webdriver’a и окон происходят внутри всякого шага. Отчего бы не совместить эти функциональности?

Тут мой StepListener. Он делает все тоже самое, что и прародитель, только не фотографирует. Фотки он получает «снаружи» и преобразует в читаемый для thucydides вид. По окончании теста происходит синхронизация собранных итогов и скриншотов. Данный агент инициализируется по инструкции, которая описана в этой статье
.
В итоге, дозволено просматривать такое слайд-шоу:
image
1и 3.

— …и как верно делать.

Эксперимент я считаю удачным – своих целей я добился. Впрочем проведен он был грубо. Повод – я хотел настраивать план снаружи, а не по стандартным правилам thucydides (которые мне кажутся необоснованно трудными). Я обещал описать верный ход мыслей, в том числе описать очерк решения этой же задачи…

У меня есть безусловно пустой класс, тот, что, как оказалось, несет дюже пригодную функцию. Узнать это удалось позже дальнейшего больше детального прочтения инструкций Jbehave. Оказывается, если бы я наделил его логикой, то тогда бы он мог оказывать воздействие на каждый запуск тестов.

Если применять данный файл в качестве внешней настройки параметров, тогда выполнение настройки могло бы выглядеть так (для примера хватит). Ниже показано, что будет открываться ожидаемый браузер (Chrome).
image

Если пройти по ссылке, что представлена дальше, то дозволено увидеть альтернативный вариант создания объектов, описывающих взаимодействие с приложением. Ссылка. Все, что должно быть дальше, будет схоже на модель, описанную ранее. Изложение тестов станет огромнее схожим на то, что предлагают разработчики thucydides. Правда, это не освобождает от обычной необходимости подстраиваться под проверяемое поведение.

На этом все, потому как глава получилась огромная! Кому увлекательно посмотретьитог, милости умоляю наgithub.

6. Послесловие и допустимые планы.

Верю, что статья кому – то в чем-то помогла. Увлекательны мысли и комментарии публики. Я бы дюже хотел, Дабы со мною кто-нибудь поделился своими лучшими практиками применения подходов behavior driven development и фрэймворка thucydides.

Что касается меня, мне было бы увлекательно копнуть глубже в Jbehave, а так же cucumber-jvm.

Что касается моего «велосипеда», то его последующее грядущее пока не ясно. Но хотелось бы:
— провести подобный эксперимент с применением Selenide;
— проверить его вероятности на мобильных приложениях с применением AppiumSelendroid и ios-driver;
— испытать в настоящих, боевых условиях;
— переименовать план на что-то больше внушительное, написать документацию и выложить в общедоступный maven – репозиторий. Пока каждая сборка происходит локально.

А пока, каждому спасибо за внимание. До встречи!

 Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB