Automated UI testing done right (DDDSydney)

Post on 25-Dec-2014

13,212 views 2 download

description

Many teams try Automated UI Testing and many fail. Automated UI Testing is hard: the tests take a lot of time to write and tend to be brittle and hard to maintain. In this session I will provide you with some practical advice on how to and how not to write your tests introducing you to some UI testing ideas, patterns and frameworks that will help you write your tests faster while making them less brittle and easier to maintain. This is an action packed session for testing enthusiasts.

transcript

Automated UI Testing

Done Right

Mehdi KhaliliSenior Developer at Readify

Active Open Source Projects:• BDDfy• Seleno• Humanizer

Blog: www.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

In a nutshell

• UI Testing: a likely failure• From horrid to awesome in three steps• A few tips (time permitting)• Q&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

a lot of teamsthen struggle with

UI Testing

a lot of teamsthen fail atUI Testing

because UI Tests are

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 four 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 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

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

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

proceduralduplicating logicduplicating selectorsmagic strings

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?

care about your tests

as much as you care about 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

lead into

S.R.P.

Page Object &Page Component

D.R.Y.your test

... but

what about magic strings?

proceduralduplicating logicduplicating selectorsmagic strings

it is not only about

magic strings

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

write your UI Tests based on

acceptance criteria

use a BDD framework to implement your

acceptance criteria

use a BDD framework to turn your tests into

living documentation

use the test results

as a progress report

use the test results

as a support for manual testing

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

when Done Right it is

well worth it

thanks for attending

time for a few Qs & hopefully few As

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

http://www.mehdi-khalili.com/presentations/automated-ui-testing-done-right-at-dddsydney

With thanks to our sponsors

Please complete your feedback forms, and return

them to the registration desk for a chance to win a

Nokia Lumia