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

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

Anna | 3.06.2014 | нет комментариев
Всем здравствуй!

Эта статья является продолжением моей прошлой публикации Про Selenium и один «велосипед», в которой я попытался описать прототип некоторого решения, которое мог бы применять на нынешнем месте работы для тестирования клиентской части вэб — приложения. Родилось оно вследствие желанию углубленно разобраться с вероятностями Selenium API.

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

А так же увлекателен взор на идеи дилетанта тех, кто теснее съел тут стаю собак. Я постараюсь лаконично описать некоторый эксперимент.

Выходит, поехали!

План:
1. Флэшбэк.
2. В чем суть эксперимента?
3. Отчего BDD?
4. Немножко про thucydides.
5. Эксперимент.
— Что должно было получиться.
— Модель взаимодействия с приложением.
— Тесты
— … и как верно делать.
6. Послесловие и планы.

1. Флэшбэк.

image
Если Добросовестно, в своем прошлом посте я рассчитывал на какую-то конструктивную критику либо на какие-то дорогие советы. В тезисе, все это я получил, но не в том объеме, на тот, что верил. Остапа тогда понесло… Постараюсь вести свое повествование сжато и доносить мысли в концентрированном виде, но с логическими итогами.

Лаконично еще раз пройдусь по оглавлению предыдущей главы. Основные идеи заключаются том, Дабы:

— поддерживать уйма реализаций WebDriver’а и для создания применять исключительный метод.
— облегчить доступ к реализациям других пригодных интерфейсов, входящих в состав Selenium API;
— вероятность поддерживать несколько открытых экземпляров WebDriver’а в одном выполняющемся тесте. Согласитесь, что может появиться обстановка, когда мы хотим проверить с точки зрения пользователя совместную работу с некоторым доступным компонентом (скажем, документом Google drive либо Яндекс диск, находящемся в совместном доступе).
— упростить изложение интерактивного взаимодействия с приложением, чьи страницы могут открываться в других окнах браузера либо вкладках, а так же содержать фрэймы. Одно из решений — автоматизация переключений объекта Webdriver’а.

— и, на мой взор, самое основное – составлять изложение тестируемого приложения с точки зрения составляющих его компонентов (страниц/окон/вкладок и т.д.), методов взаимодействия с ними. За пример было взято вот это.
image
Это дерево объектов. Вид из TestComplete. Допустимо, пример не самый успешный. Т.е. дерево структурных компонентов, как примитивных, так и трудных. Трудные компоненты могут быть описаны в виде классов, которые дозволено наследовать. Объекты этих классов дозволено применять, причем единовременно и в различных местах.

Среди существующих инструментов поверх Selenium Webdriver я бы выделил Yandex-qatools Htmlelements. Он реализует схожий правило. Но, как мне показалось, он описывает физически объединенные между собой типизированные элементы, которые потом группируются в изложения проверяемых вэб-страниц. Это предположение дозволено оспорить.

Я же, как мне кажется, пытаюсь выделить повторяющиеся элементы, которые может быть физически не связанны до некоторых пределов (не объединены каким-нибудь div’ом, скажем), но коллективно присутствуют и исполняют всеобщую функцию либо комплект функций. Эти комплекты дозволено расширить за счет наследования, дозволено спрятать один внутри иного либо передать наружу (скажем, в тест) для последующей работы. Может получиться трудный Page Object.

Хочу, при острой необходимости, Дабы внутри такого контейнера дозволено было применять другие инструменты, работающие с Webdriver и исполняющие те либо иные функции отменнее. В прошлый раз я мимоходом описал пример совместного применения того, что получилось и теснее упомянутого Htmlelements. Дюже хочется провести такой эксперимент с Selenide.

Но, при всех описанных плюшках, я считаю, что процентов 60-70 всех тестов (не поменьше) обязаны быть unit-тесты и тесты бэк-энда. А все остальное – тесты, которые могут сказать, что пользователь сумеет трудиться с финальным продуктом.

— примитивные кастомизация и деплой;
— придумать прекрасные плюшки. Скажем, комплект прекрасных интерфейсов и их «стандартных» реализаций, которые, к примеру, разрешают определенным образом обрабатывать некоторые исключительные обстановки, фиксировать события webdriver’а, открытого окна/вкладки и т.д. Ниже показан итог (пока еще грубый) работы одной такой реализации. Она перехватывает сообщения лога и трансформирует их в детализацию отчета TestNG.
Отчет. Скриншот.

image

С момента публикации удалось:
— добавить поддержку PhantomJS;
— немножко усовершенствовать образование детализации отчета TestNG. Позднее, я перенес эти инструменты в обособленный артефакт;
— оптимизировать начальный код, убрать лишние детали. 
— окончательно сформировать модель изложения приложения. Ее составляющие:

IDecomposable.java;
FunctionalPart.java – это то, что в предыдущей статье именовалось Page;
Entity.java – представление открытого заказчика в целом.
Наглядно каждая модель представлена ниже.
image
— комфортная и эластичная настройка полагаемого плана. Пример в формате JSON. Дозволено сделать одну обобщенную конфигурацию и дозволено сделать несколько других, которые ее Отчасти перекроют и будут использованы для уточнения либо в виде параметров для создания самых различных объектов.
— многое другое, но все это не поместится в формат одной статьи. Если в этом есть толк, то опишу позднее.

Ссылка на нынешний итог.

2. В чем суть эксперимента?

image
С недавних пор у меня возник интерес к behavior driven development как к некой доктрины, а так же к инструментам, которые применяются для изложения проводимых тестов в сходственном ключе. Стало увлекательно, сумеет ли мой продукт быть использован как один из элементов стека такого автотестирования?

Помимо того, мне было увлекательно, сумеют ли два инструмента, которые возведены на применении дизайн-паттерна Page Object ужиться, органично дополняя друг — друга имеющимися пригодными вероятностями? Идея может и абсурдная, но думаю, может быть увлекательна как исследовательская задача. И, в качестве итога, поделиться с публикой своими соображениями.

Следственно, эксперимент был проведен с применением фрэймворка thucydides, т.к. это особенно знаменитый инструмент, в котором все выше названное максимально представлено. Для этого я применял версии 0.9.227 — 229 thucydides-core.

В качестве подопытного кролика, в силу некоторых особенностей, был выбран вэб-заказчик 1С.

P.S. Хочу извиниться перед фирмой 1С, если замусорил список контрагентов, и это принесло неудобства. Но, думаю, это послужило благим целям.

3. Отчего BDD?

image
У меня нет цели описать данный подход со всеми его превосходствами и недостатками. Для этого я порекомендую прочитать это и это, и еще много других источников.

Я отменнее расскажу, отчего такой подход может показаться увлекательным кому-то и показался увлекательным мне с точки зрения его применения в автоматизированном тестировании:
— отделение логики теста от кода, тот, что что-то проверяет либо исполняет то либо иное действие;
— вероятность описывать автоматизированные тесты простым человеческим языком, хоть и не в свободной форме;
— каждая нагрузка при автоматизации приемочного тестирования сейчас смещается в сторону разработки и поддержки отдельных тестовых процедур (способов каких-либо классов), а не автоматизированного теста целиком;
— ну и, как подсказывает кэп, повторное применение описанных тестовых процедур;
— универсальность. Мне кажется, такой подход дозволено применять как в приемочном тестировании, так для выполнения unit-тестов.

Представим, что у меня есть сценарий, описанный и хранящийся в TestLink, скажем:

1. Do something
2. Do another action
3. Do one more action. Something is expected.

Ok! Тест дозволено описать так:

  @Test
  public void someTest()
  {
	  //Step 1. Do something
	  //much code

	  //Step 2.	Do another action
	  //much code

	  //Step 3.	Do one more action.
	  //much code

	  //Checking the result
	  //Some assert

	  //ect.
  }

Чуть отменнее смотрится это:

  public void doSomething(Object... params)
  {
	//much code 
  }

  public void doAnotherAction(Object... params)
  {
	//much code
  }

  public void doOneMoreAction(Object... params)
  {
	//much code
  }

  public void checkOutResult(Object... params)
  {
	//Some assert 
  }

  @Test
  public void someTest()
  {
	  //Step 1. Do something
	  doSomething();	  
	  //Step 2.	Do another action
	  doAnotherAction();	  
	  //Step 3.	Do one more action.
	  doOneMoreAction();

	  //Checking the result
	  checkOutResult();

	  //ect.
  }

Должен сознаться, что в силу некорых технических ограничений, выше описанные реализации доводится непрерывно следить, да и самому описывать автотесты в сходственном ключе. Чем мне такой подход не нравится, так это тем, что в случае метаморфозы логики проверки придется переделывать каждый тест (метод/группу методов/целый класс) и скорее каждого, не один.

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

Испробуем описать данный тест с применением, скажем, фрэймворка Jbehave.
У меня получился класс с такими способами:

  @Given("Do something")
  public void doSomething(Object... params)
  {
	//much code 
  }

  @Given("Do another action")
  public void doAnotherAction(Object... params)
  {
	//much code
  }

  @When("When do one more action.")
  @Given("One more action is done")
  public void doOneMoreAction(Object... params)
  {
	//much code
  }

  @Then("Something is expected")
  public void checkOutResult(Object... params)
  {
	//Some assert 
  }

То, что описано в левой части пунктов 1 и 2 моего сценария, является предусловием (Given), при выполнении которого дозволено переходить к 3. В левой части 3 описано действие, которое необходимо проверить (When), правда при других обстоятельствах оно может оказаться предусловием (Given). И в правой части сама проверка (Then). Стоп, а где сам тест? Он ниже, написанный в блокноте, имеющий растяжение *.story:

Scenario: Some test
Given Do something
And Do another action
When Do one more action.
Then Something is expected

Последующие наши шаги, я думаю очевидны. Мы сумеем составить маленький тестовый план применяя только эти реализованные шаги и изложения пускай на формализованном, но человеческом языке.

Я не хочу проводить огромную и тоскливую лекцию о вероятностях изложения тестов в BDD-зове на Jbehave, ну правда бы потому, что я сам пока неудовлетворительно обладаю инструментом – не хватило времени на его большое постижение и применение.

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

4. Немножко про thucydides.

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

Нужно сказать, что его так назвали не напрасно, т.к.:
— Интеграция «из коробки» с Jbehave;
— Комплект дополнительных хелперов, скажем шаги;
— Интеграция с баг-трэкерами;
— Вероятности прослушивать исполняемые шаги с поддержкой реализаций интерфейса StepListener.
— Ну и, безусловно, прекрасные отчеты, которые есть «в коробке», и которые, глядя на исходники, дозволено делать самим. Пример 1пример 2 и пример 3;
— А так же комплект вспомогательных инструментов для работы со страницами вэб -приложений и их элементами. Их дозволено посмотреть, скажем, тут и тут

Впрочем:
— он легко велик. Не уверен, что существует много планов (имею право на гипотезы), где применяется правда бы 50% того, что в него вложено. Изготавливает ощущение обвертки вокруг каждого, чего только дозволено;
— я считаю, что усложненный деплой, т.к. многие настройки и параметры, если без каких-либо дополнительных усилий, необходимо указывать в системных свойствах. Хотелось бы, Дабы эти настройки переносились совместно с локальным чек аутом плана из репозитория;
— из разговоров с некоторыми товарищами сложилось ощущение, что реализация чего-то нетривиального может принудить серьезно задуматься. Средства есть, но они неочевидны. Пример.
Но многие пользуются этим инструментом, он себя зарекомендовал. А чего бы самому не испробовать?!

Кому увлекательно продолжение, глядеть тут.

Источник: programmingmaster.ru

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