automated ui testing done right (dddsydney)
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