Automated UI Testing

Done Right

Mehdi KhaliliSenior Developer at Readify

Active Open Source Projects:• BDDfy• Seleno• Humanizer

Blog: www.mehdi-khalili.comEmail: me@mehdi-khalili.comTwitter: @MehdiKhalili

These practices are performed by professional developers and testers.

Please DO try this at home

Authorized and written by Mehdi Khalili

framework agnostic ideas and patterns

can apply these with any UI and UI Testing framework

… but for this talk we are going to use

Seleniuman awesome automated UI testing

framework

Seleniumhttp://seleniumhq.org/projects/webdriver/

PM> Install-Package

Selenium.WebDriver

BDDfyA simple BDD framework to use and extend!

BDDfy turns your traditional unit testsinto BDD behaviours

BDDfyhttp://teststack.github.com/TestStack.BDDfy/

PM> Install-Package

TestStack.BDDfy

Selenohelps you write

Automated UI Tests the RIGHT way!

Selenohttp://teststack.github.com/TestStack.Seleno/

PM> Install-Package TestStack.Seleno

samples are from Seleno codebase and can be found at

https://github.com/TestStack/TestStack.Seleno

Agenda

UI Testing: a likely failureFrom horrid to awesome in three stepsA few tipsQ&A

UI Testing!a likely failure

speaking of experience

a lot of teamsdo

UI Testing

a lot of teamshave a great start at

UI Testing

theythen struggle with

UI Testing

and a lot of teamsthen fail atUI Testing

because UI Tests are

because UI Tests are

hard to write

because UI Tests are

hard to maintain

because UI Tests are

brittle

but

you can

mitigatethese issues

If you

do it

RIGHT

test codeis

code

apply

S.R.P. on your

code?

apply

S.R.P.on your

tests

apply

D.R.Y.on your

tests

care about your

tests as much as you care about your

code

or you willwaste a lot of time

or you willfail

from horrid to awesomein three steps

a quick look at the sample

https://github.com/TestStack/TestStack.Seleno

guaranteed to

fail

proceduralduplicated logicduplicated selectorsmagic strings

Step 1:

D.R.Y.your tests with

Page Object

Page Objectbrings

OO to tests)

a Page Object per page under test

a textboxon the page becomes a

string propertyon the Page Object

filling a textbox on the page turns into setting a string property on the

Page Object

instead of

you will get

a checkboxon the page becomes a

bool propertyon the Page Object

ticking a checkbox on the page turns into setting a

bool property on the Page Object

a link on the page becomes a

method on the Page Object

clicking a link on the pageturns into calling a method

on the Page Object

instead of

you will get

any actionon the page becomes a

method on the Page Object

… and you will get another Page Object as the return

value of the method

chain your calls

step 2:

Page Components

Compose your Page Objects of smaller pieces

some pages are

big

some pages are

complex

remember

S.R.P.?

would you write

big and

complex classes in your

code?

do NOT write

big and

complex Page Objects

use

Page Componentsto break down your

Page Objects

use

Page Componentsfor

gridspanels

rows inmodal pop-ups

menus

Page ComponentsD.R.Y.

your tests even more

instead of

you will get

and you can compose other

Page Objectsusing these

Page Components

Page Object &Page Component

D.R.Y.your test

Page Object &Page Component

lead into

S.R.P.

proceduralduplicating logicduplicating selectorsmagic strings

… and the code is still

ugly

step 3:

Strongly typedPage Object

you use view models

in your code

why not use view models

in your tests?

(unofficial) step 4:

Tests as Living Documentation

how do you get

requirements from the business?

asked to work one a new feature or a bug

programmer: “can I see the req. for this?”

feeling very proud for generating the most awesome requirements

BA: “here you go”

requirements book, anyone!?!

requirements in Word ===

a lot of wasted time

requirements in Word ===

out of date requirements

requirements in Word ===

a lot of confusion

requirements in Word ===

misinterpretation

requirements in Word ===

wrong product

BDD to the rescue

http://www.mehdi-khalili.com/bdd-to-the-rescue

BDD to the rescue

reducing misinterpretation

BDD to the rescue

YAGNI

BDD to the rescue

early and frequent feedback

BDD to the rescue

test suite defined by BAs

BDD to the rescue

living documentation

write your UI Tests based on

acceptance criteria

use a BDD framework to implement your

acceptance criteria

use the test results

as a progress report

use the test results

to support and reduce manual testing

computers are having fun while we are doing the repetitive tasks they are built to do

A few tips

Do NOT use Thread.Sleep

Thread.Sleepis slow

Thread.Sleepis brittle

often need to wait a bit longer for things to load?

use implicit waits

need to wait longer for specific elements to load?

use explicit waits

need to wait for an AJAX call to finish?

use javascript

chooseright selectors

page structure changes

do NOT

be fuzzywith your selectors

do NOT

rely on the structure of your

page

do NOT

rely on the surrounding elements

By.XPath("//ul[@id='album-list']/li[3]/a/span")

you’re kidding, right?!

we use interfaces and DI all over our code to make it unit testable

do what it takes to

support your tests

be explicit:add id on your elements to

support your tests

TARGET your elements

directlywhen possible

only one test

per action

do you have workflows?

do one test per page/action

then do one test for entire flow

do NOT setup your required

state through UI

that will be slow and brittle

setup your data through code

and navigate to the page under

test directly

use strongly typed actions for that

design byinterface!

when you need it

do you support multiple devices?

do you doA/B testing?

create interface for your Page Objects and

use the interface in your test scripts

ISomePage

PCPage A/B testing pages iPadPage

… and use one test script for all page variations

apply

YAGNIin your

test code

do

NOTcreate a

Page Object

until you need it

do

NOTadd an action to

Page Object

until you need it

do

NOTadd a property to

Page Object

until you need it

do

NOTadd a getter to your property

until you need it

run and maintain your tests

run your tests

frequently

fix the broken test right

when it breaks

tests you do not run

===broken tests

broken tests you do not fix

===ignored tests

… and finally

Confucius says …

UI Testing is hard

and could be a waste of time

so

do NOT do itor

do it RIGHT

thanks for attending

time for a few Qs & hopefully few As

Blog: www.mehdi-khalili.comTwitter: @MehdiKhalili