Automated UI Testing Done Right (QMSDNUG)

Automated UI Testing Done Right

Mehdi Khalili Senior Developer at Readify Active Open Source Projects: • BDDfy • Seleno • Humanizer Blog: www.mehdi-khalili.com Email: me@mehdi-khalili.com Twitter: @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

Selenium an awesome automated UI testing framework

Selenium http://seleniumhq.org/projects/webdriver/ PM> Install-Package Selenium.WebDriver

BDDfy A simple BDD framework to use and extend! BDDfy turns your traditional unit tests into BDD behaviours

BDDfy http://teststack.github.com/TestStack.BDDfy/ PM> Install-Package TestStack.BDDfy

Seleno helps you write Automated UI Tests the RIGHT way!

Seleno http://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 failure From horrid to awesome in three steps A few tips Q&A

UI Testing! a likely failure speaking of experience

a lot of teams have a great start at UI Testing

they then struggle with UI Testing

and a lot of teams then fail at UI Testing

because UI Tests are hard to write

because UI Tests are hard to maintain

but you can mitigate these issues

care about your tests as much as you care about your code

or you will waste a lot of time

from horrid to awesome in three steps

a quick look at the sample https://github.com/TestStack/TestStack.Seleno

procedural duplicated logic duplicated selectors magic strings

Step 1: your tests with Page Object

Page Object brings OO to tests

a Page Object per page under test

textbox a on the page becomes a string property on the Page Object

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

acheckbox on the page becomes a bool property on 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 page turns into calling a method on the Page Object

anyaction on the page becomes a method on the Page Object

… and you will get another Page Object as the return value of the method

step 2: Page Components Compose your Page Objects of smaller pieces

would you write big and complex classes in your code?

do NOT write big and complex Page Objects

use Page Components to break down your Page Objects

use Page Components for panels menus rows in grids modal pop-ups

Page Components D.R.Y. your tests even more

and you can compose other Page Objects using these Page Components

Page Object & Page Component D.R.Y. your test

Page Object & Page Component lead into S.R.P.

procedural duplicating logic duplicating selectors magic strings

… and the code is still ugly

step 3: Strongly typed Page 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 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 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

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

need to wait longer for specific elements to load?

need to wait for an AJAX call to finish?

do NOT be fuzzy with 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 directly when possible

then do one test for entire flow

do NOT setup your required state through UI

and navigate to the page under test directly

use strongly typed actions for that

design by interface! when you need it

do you support multiple devices?

create interface for your Page Objects and use the interface in your test scripts

ISomePage A/B testing PCPage iPadPage pages

… and use one test script for all page variations

do NOT create a Page Object until you need it

do NOT add an action to Page Object until you need it

do NOT add a property to Page Object until you need it

do NOT add a getter to your property until you need it

fix the broken test right when it breaks

tests you do not run === broken tests

broken tests you do not fix === ignored tests

so do NOT do it or do it RIGHT

time for a few Qs & hopefully few As Blog: www.mehdi-khalili.com Twitter: @MehdiKhalili

Automated UI Testing Done Right (QMSDNUG)

More Related Content

What's hot

Similar to Automated UI Testing Done Right (QMSDNUG)

Recently uploaded

Automated UI Testing Done Right (QMSDNUG)

Editor's Notes