Automated UI testing done right (DDDSydney)
Upcoming SlideShare
Loading in...5
×
 

Automated UI testing done right (DDDSydney)

on

  • 11,810 views

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

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.

Statistics

Views

Total Views
11,810
Views on SlideShare
2,901
Embed Views
8,909

Actions

Likes
0
Downloads
38
Comments
1

10 Embeds 8,909

http://www.mehdi-khalili.com 8860
http://mehdi-khalili.com 19
http://localhost 10
http://www.linkedin.com 5
http://theoldreader.com 5
http://translate.googleusercontent.com 4
http://www.directrss.co.il 2
http://127.0.0.1 2
http://www.netvibes.com 1
http://inoreader.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Fantastic!!!
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • The framework is called BDDfy because it BDDfies (as in turns into BDD) your otherwise traditional unit tests
  • The framework is called BDDfy because it BDDfies (as in turns into BDD) your otherwise traditional unit tests
  • Some code here + demoWhy it is different from the previous approachBut changing a name still breaks the tests
  • Show a demo of a change on an id that breaks a test
  • Show a demo of a change on an id that breaks a test
  • Showing the demo with PageShowing the differenceShowing that changing a property name gives compile time error
  • UI Tests are no different
  • Add a photo of an element being targetted

Automated UI testing done right (DDDSydney) Automated UI testing done right (DDDSydney) Presentation Transcript

  • Automated UI TestingDone Right
  • Mehdi KhaliliSenior Developer at ReadifyActive Open Source Projects: • BDDfy • Seleno • HumanizerBlog: www.mehdi-khalili.comTwitter: @MehdiKhalili
  • These practices are performed byprofessional developers and testers.Please DO try this at homeAuthorized and written by Mehdi Khalili
  • framework agnostic ideas and patterns
  • can apply these with anyUI and UI Testing framework
  • … but for this talk we are going to use
  • Seleniuman awesome automated UI testing framework
  • Selenium http://seleniumhq.org/projects/webdriver/PM> Install-Package Selenium.WebDriver
  • BDDfyA 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 writeAutomated UI Tests the RIGHT way!
  • Seleno http://teststack.github.com/TestStack.Seleno/PM> Install-Package TestStack.Seleno
  • samples are from Selenocodebase 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 ofexperience
  • a lot of teams do UI Testing
  • a lot of teamshave a “great start” at UI Testing
  • a lot of teamsthen struggle with UI Testing
  • a lot of teams then fail at UI Testing
  • because UI Tests are
  • because UI Tests arehard to maintain
  • because UI Tests are brittle
  • but you canmitigatethese issues
  • If you do itRIGHT
  • test code is code
  • applyS.R.P.on yourcode?
  • applyS.R.P.on yourtests
  • applyD.R.Y.on yourtests
  • care about yourtests as much asyou care about your code
  • or you willwaste a lot of time
  • or you will fail
  • from horrid to awesome in four three steps
  • a quick look at the samplehttps://github.com/TestStack/TestStack.Seleno
  • guaranteed to fail
  • proceduralduplicated logicduplicated selectorsmagic strings
  • Step 1:your tests with Page Object
  • Page Object brings OO to tests
  • a Page Object per page under test
  • a link on the page becomes amethod on the Page Object
  • clicking a link on the pageturns into calling a method on the Page Object
  • instead ofyou will get
  • textbox aon the page becomes astring property on the Page Object
  • filling a textbox on thepage turns into setting a string property on the Page Object
  • instead ofyou will get
  • acheckboxon the page becomes abool property on the Page Object
  • ticking a checkbox on the page turns into setting a bool property on the Page Object
  • anyactionon the page becomes a method on the Page Object
  • … and you will get anotherPage Object as the return value of the method
  • chain your calls
  • proceduralduplicating logicduplicating selectorsmagic strings
  • step 2: Page ComponentsCompose your Page Objects of smaller pieces
  • some pages are
  • some pages arecomplex
  • rememberS.R.P.?
  • would you writebig and complex classes in your code?
  • care about your tests as much asyou care about your code
  • do NOT writebig and complex Page Objects
  • usePage Components to break down your Page Objects
  • usePage Components forpanels menus rows in gridsmodal pop-ups
  • Page Components D.R.Y. your tests even more
  • instead ofyou will get
  • and you cancompose other Page Objects using thesePage 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 aboutmagic strings
  • the code is still ugly
  • step 3:Strongly typed Page Object
  • you useview models in your code
  • why not useview modelsin your tests?
  • (unofficial) step 4: Tests as LivingDocumentation
  • write your UI Tests based onacceptance criteria
  • use a BDD framework to implement youracceptance criteria
  • use a BDD framework to turn your tests intoliving documentation
  • use the test results as aprogress report
  • use the test resultsas a support formanual testing
  • Afewtips
  • Do NOT useThread.Sleep
  • Thread.Sleep is slow
  • Thread.Sleep is brittle
  • often need to wait a bitlonger for things to load?
  • use implicit waits
  • need to wait longerfor specific elements to load?
  • use explicit waits
  • need to wait for anAJAX call to finish?
  • use javascript
  • chooseright selectors
  • page structure changes
  • do NOT be fuzzywith your selectors
  • do NOTrely on the structure of your page
  • do NOT rely on thesurrounding elements
  • By.XPath("//ul[@id=album-list]/li[3]/a/span") you’re kidding, right?!
  • we use interfaces andDI all over our code to make it unit testable
  • do what it takes tosupport your tests
  • be explicit: add id on your elements tosupport your tests
  • TARGETyour elements directly when possible
  • only one testper action
  • do you haveworkflows?
  • do one test per page/action
  • then do one test for entire flow
  • do NOT setup your requiredstate through UI
  • that will beslow and brittle
  • setup your data through code
  • and navigate tothe page under test directly
  • use strongly typed actions for that
  • design byinterface! when you need it
  • do you supportmultiple devices?
  • do you doA/B testing?
  • create interface foryour Page Objects and use the interface in your test scripts
  • ISomePage A/B testingPCPage iPadPage pages
  • … and use onetest script for all page variations
  • applyYAGNI in yourtest code
  • do NOT create a Page Objectuntil you need it
  • do NOT add an action to Page Objectuntil you need it
  • do NOT add a property to Page Objectuntil you need it
  • do NOT add a getter to your propertyuntil you need it
  • run and maintain your tests
  • run your testsfrequently
  • fix the broken test rightwhen 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 awaste of time
  • sodo NOT do it ordo it RIGHT
  • when Done Right it is well worth it
  • thanks for attending
  • time for a few Qs & hopefully few AsBlog: www.mehdi-khalili.comTwitter: @MehdiKhalilihttp://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 theregistration desk for a chance to win a Nokia Lumia