Step objects

Step Object

passive developer

of active tests

Tim Sukhachev

Step Object Demo:

https://github.com/tsuhachev/steppy

6+ years in industry

Agenda

• Intro

• Step Object Layer

• Thucydides

• Generic steps

• Step and Data Logistics

• Step manifesto

Tech demo

Tech demo

Tim Sukhachev, 02/24/2013

Добрый деньДавайте начинать Я начну с описния проблемы, с которой я столкнулся и как я пришел к потребности использования Step ObjectДалее мы узнаем, что такое So, где и как его применять Ну и конечно же посмотрим его применение на практике: в этом нам поможет thucydidesЗатем вы увидите как можно использовать generic для создания step helpers Так как любое тестирование оперирует некими данными, мы рассмотрим механизм управления этими данными в SOНу и на последок, мы попробуем с вами описать манифест SO - каким правилам нужно следовать, что бы успечно его применять

Looks like happiness, eh?

BDD / TDD

WebDriver

Page Object


Kuoni - это третий проект, в котором я использую webdriver, и все предидущие проекты я начинал со связки PO + Webdriver + Junit Tests. В текущем вместо Junit tests мы используем описание поведения, однако картины в целом это не меняет. Казалось бы, что еще нужно ... есть API для общения с браузером , API страниц, и слой , в котором я его использую

It's like .. too detailed DSLEach ''step” is locked in its “page space”

My first test ...


Действительно, я описываю логику теста, либо поведениеСначала, когда страниц 3-4, все кажется гладко Но проект растет, количество страниц увеличивается Ты понимаешь , что , что бы провести тестирование некого end-to-end сценария тебе нужно 20 + страниц , 5+ пользователей и просто невероятное количество тестовых данныхПонимешь, что изначального набора уже недостаточно ... понимаешь, что дсл, который уже написан в PO слишком детален и содержит уйму методов, которые вобщем-то исользуются один раз

Yes, that's page object


Вот скажем API одной из страницКогда тестов не очень много , ты не задумываешься о том , какой API у страницыТебе нужен метод , который нажимает на кнопку или возвращает текст какого-то элемента ... написать его простоНаписал и забыл :)

And finally … stuck

ending up with 600+ rows of similar code


Даже десяток подобных тестов поддерживать уже очень сложно Появляются методы, которые переписывать просто нет времени, так как обьем функционала вырос Появляются @deprecated методы, потом появляются @deprecated тесты И в конце концов ты понимаешь, что застрял ... сам tdd процесс становится слишком тяжелымВот собственно момент, когда я понял что первоначальный набор webdriver + page object уже не делает никого счастливым ..Нужна прослойка, которая бы содержала в себе накопленный функционал ... нужен простой API для работы с существующей функциональностью

Step Object

Behavior / Tests

Page Object

Element Object

Step Object is already not a page object …

Step Object is in between!

And notbehavior yet …


Давайте разберем, какую нишу должен занимать такой API По сути своей, задача разработчика тестов заключается в том, что бы написать приложение, которое тестируем собственно продуктЛюбой тестовый фреймворк так или иначе имеет такую архитектуруЕсть прослойка, где мы пишем тесты, используя дсл. Есть прослойка page object, в которой мы вызываем более низкоуровневый API элементов страницы. И самая базовая прослойка - element object, содержая реализацию API элементов страницы. SO – это высокоуровневая прослойка, содержащая в себе реализацию шагов, которые доступны в рамках тестируемого продукта. Это уровень бизнес логики.

Set and Get

Act and Verify

Given, When, ThenBehavior

Step Object

Page Object

Standard/Custom Elements APIElement Object


Мы убрали пирожок ... Давайте теперь посмотрим на scope каждого из слоев С тестами вроде бы как все ясно – мы можем частично перености на уровень SO assertions, ну а что с PO ?Давайте оставим там только описание локаторов элементов, и setters / getters значений для нихНемного позже я покажу , насколько сужается PO и насколько понятнее становится его использование

Given I arrived to airport

When I pass luggage and ticket control

Then I’m on board

Passenger calls taxi

Passenger pays driver

Passenger passes luggage control

Passenger passes gate contol

Passenger gets the place

Passenger enjoys the flight

Departure, Epic Feature


Ну и конечно же нам не обойтись без примера ...У нас есть сценарий для некой крупной функциональности - Departure feature Каждое из поведений можно разбить на бизнес шагиУ шагов, как и у поведения, есть автор - персона, у которой есть доступ к этой фунциональности

Departure

Taxi

Board

Airport

Local Steps

passenger.departs()

Global Leaps

passenger.atTaxi().paysForShuttle()


Схематично это выглядит примерно такЕсть некая функциональная карта , в которой действия персоны в такси являются локальными, но есть и глобальный шаг , агрегирующий в себе несколько – passenger.departs()

All Steps Package

Actor package

Step FactorySteps

Step Group

Tech Corner

Generic Steps

populate(WHAT, WHERE)

Tech Corner

WHAT: E extends EntityWHERE: P extends PageObject

Generic steps requires: ✔ Generic way of getting /

setting element regardless of a

tag - Basic HTML or any custom

✔ Business object (entity)

✔ Reflection / BeanUtils

Data Estafette

No need to know ticket number …

Just hand it over!

I don't need to remember passport details

I just show it!

Data hand over principles

Tech Corner

Step Manifesto

• Act on behalf

• Align local steps across feature, and global - across application

• Be generic

• Let your steps operate data

Step objects

Documents

Transcript of Step objects