automated ui testing done right (qmsdnug)
TRANSCRIPT
Automated UI Testing
Done Right
Mehdi KhaliliSenior Developer at Readify
Active Open Source Projects:• BDDfy• Seleno• Humanizer
Blog: www.mehdi-khalili.comEmail: [email protected]: @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