Automated UI Testing Done Right (QMSDNUG)

  • 2,183 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Thanks @jameswangz@michellepavel Sorry I missed your comment and it's a year old now! Do'h. That was the conversion to SlideShare unfortunately. You can see the session recording on http://www.mehdi-khalili.com/presentations/automated-ui-testing-done-right-at-dddsydney
    Are you sure you want to
    Your message goes here
  • Very inspiring, full of information.
    Are you sure you want to
    Your message goes here
  • I don't know if it is just the conversion to SlideShare but this presentation is in a really bad format and is not user friendly. I made it to slide 26.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
2,183
On Slideshare
0
From Embeds
0
Number of Embeds
7

Actions

Shares
Downloads
19
Comments
3
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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
  • Showing the demo with Page<T>Showing the differenceShowing that changing a property name gives compile time error
  • UI Tests are no different
  • Add a photo of an element being targetted

Transcript

  • 1. Automated UI TestingDone Right
  • 2. Mehdi KhaliliSenior Developer at ReadifyActive Open Source Projects: • BDDfy • Seleno • HumanizerBlog: www.mehdi-khalili.comEmail: me@mehdi-khalili.comTwitter: @MehdiKhalili
  • 3. These practices are performed byprofessional developers and testers.Please DO try this at homeAuthorized and written by Mehdi Khalili
  • 4. framework agnostic ideas and patterns
  • 5. can apply these with anyUI and UI Testing framework
  • 6. … but for this talk we are going to use
  • 7. Seleniuman awesome automated UI testing framework
  • 8. Selenium http://seleniumhq.org/projects/webdriver/PM> Install-Package Selenium.WebDriver
  • 9. BDDfyA simple BDD framework to use and extend! BDDfy turns your traditional unit tests into BDD behaviours
  • 10. BDDfy http://teststack.github.com/TestStack.BDDfy/PM> Install-Package TestStack.BDDfy
  • 11. Seleno helps you writeAutomated UI Tests the RIGHT way!
  • 12. Seleno http://teststack.github.com/TestStack.Seleno/PM> Install-Package TestStack.Seleno
  • 13. samples are from Selenocodebase and can be found at https://github.com/TestStack/TestStack.Seleno
  • 14. AgendaUI Testing: a likely failureFrom horrid to awesome in three stepsA few tipsQ&A
  • 15. UI Testing!a likely failure speaking of experience
  • 16. a lot of teams do UI Testing
  • 17. a lot of teamshave a great start at UI Testing
  • 18. theythen struggle with UI Testing
  • 19. and a lot of teams then fail at UI Testing
  • 20. because UI Tests are
  • 21. because UI Tests arehard to write
  • 22. because UI Tests arehard to maintain
  • 23. because UI Tests are brittle
  • 24. but you canmitigatethese issues
  • 25. If you do itRIGHT
  • 26. test code is code
  • 27. applyS.R.P.on yourcode?
  • 28. applyS.R.P.on yourtests
  • 29. applyD.R.Y.on yourtests
  • 30. care about yourtests as much asyou care about your code
  • 31. or you willwaste a lot of time
  • 32. or you will fail
  • 33. from horrid to awesome in three steps
  • 34. a quick look at the samplehttps://github.com/TestStack/TestStack.Seleno
  • 35. guaranteed to fail
  • 36. proceduralduplicated logicduplicated selectorsmagic strings
  • 37. Step 1:your tests with Page Object
  • 38. Page Object brings OO to tests
  • 39. a Page Object per page under test
  • 40. textbox aon the page becomes astring property on the Page Object
  • 41. filling a textbox on thepage turns into setting a string property on the Page Object
  • 42. instead ofyou will get
  • 43. acheckboxon the page becomes abool property on the Page Object
  • 44. ticking a checkbox on the page turns into setting a bool property on the Page Object
  • 45. a link on the page becomes amethod on the Page Object
  • 46. clicking a link on the pageturns into calling a method on the Page Object
  • 47. instead ofyou will get
  • 48. anyactionon the page becomes a method on the Page Object
  • 49. … and you will get anotherPage Object as the return value of the method
  • 50. chain your calls
  • 51. step 2: Page ComponentsCompose your Page Objects of smaller pieces
  • 52. some pages are
  • 53. some pages arecomplex
  • 54. rememberS.R.P.?
  • 55. would you writebig and complex classes in your code?
  • 56. do NOT writebig and complex Page Objects
  • 57. usePage Components to break down your Page Objects
  • 58. usePage Components forpanels menus rows in gridsmodal pop-ups
  • 59. Page Components D.R.Y. your tests even more
  • 60. instead ofyou will get
  • 61. and you cancompose other Page Objects using thesePage Components
  • 62. Page Object &Page Component D.R.Y. your test
  • 63. Page Object &Page Component lead into S.R.P.
  • 64. proceduralduplicating logicduplicating selectorsmagic strings
  • 65. … and the code is still ugly
  • 66. step 3:Strongly typed Page Object
  • 67. you useview models in your code
  • 68. why not useview modelsin your tests?
  • 69. (unofficial) step 4: Tests as LivingDocumentation
  • 70. how do you getrequirementsfrom the business?
  • 71. asked to work one a new feature or a bugprogrammer: “can I see the req. for this?”
  • 72. feeling very proud for generatingthe most awesome requirements BA: “here you go”
  • 73. requirements book, anyone!?!
  • 74. requirements in Word === a lot of wasted time
  • 75. requirements in Word ===out of date requirements
  • 76. requirements in Word === a lot of confusion
  • 77. requirements in Word === misinterpretation
  • 78. requirements in Word === wrong product
  • 79. BDD to the rescuehttp://www.mehdi-khalili.com/bdd-to-the-rescue
  • 80. BDD to the rescuereducing misinterpretation
  • 81. BDD to the rescue YAGNI
  • 82. BDD to the rescueearly and frequent feedback
  • 83. BDD to the rescuetest suite defined by BAs
  • 84. BDD to the rescueliving documentation
  • 85. write your UI Tests based onacceptance criteria
  • 86. use a BDD framework to implement youracceptance criteria
  • 87. use the test results as aprogress report
  • 88. use the test resultsto support and reduce manual testing
  • 89. computers are having fun while we are doing the repetitive tasks they are built to do
  • 90. Afewtips
  • 91. Do NOT useThread.Sleep
  • 92. Thread.Sleep is slow
  • 93. Thread.Sleep is brittle
  • 94. often need to wait a bitlonger for things to load?
  • 95. use implicit waits
  • 96. need to wait longerfor specific elements to load?
  • 97. use explicit waits
  • 98. need to wait for anAJAX call to finish?
  • 99. use javascript
  • 100. chooseright selectors
  • 101. page structure changes
  • 102. do NOT be fuzzywith your selectors
  • 103. do NOTrely on the structure of your page
  • 104. do NOT rely on thesurrounding elements
  • 105. By.XPath("//ul[@id=album-list]/li[3]/a/span") you’re kidding, right?!
  • 106. we use interfaces andDI all over our code to make it unit testable
  • 107. do what it takes tosupport your tests
  • 108. be explicit: add id on your elements tosupport your tests
  • 109. TARGETyour elements directly when possible
  • 110. only one testper action
  • 111. do you haveworkflows?
  • 112. do one test per page/action
  • 113. then do one test for entire flow
  • 114. do NOT setup your requiredstate through UI
  • 115. that will beslow and brittle
  • 116. setup your data through code
  • 117. and navigate tothe page under test directly
  • 118. use strongly typed actions for that
  • 119. design byinterface! when you need it
  • 120. do you supportmultiple devices?
  • 121. do you doA/B testing?
  • 122. create interface foryour Page Objects and use the interface in your test scripts
  • 123. ISomePage A/B testingPCPage iPadPage pages
  • 124. … and use onetest script for all page variations
  • 125. applyYAGNI in yourtest code
  • 126. do NOT create a Page Objectuntil you need it
  • 127. do NOT add an action to Page Objectuntil you need it
  • 128. do NOT add a property to Page Objectuntil you need it
  • 129. do NOT add a getter to your propertyuntil you need it
  • 130. run and maintain your tests
  • 131. run your testsfrequently
  • 132. fix the broken test rightwhen it breaks
  • 133. tests you do not run ===broken tests
  • 134. broken tests you do not fix === ignored tests
  • 135. … and finally
  • 136. Confucius says …
  • 137. UI Testing is hard
  • 138. and could be awaste of time
  • 139. sodo NOT do it ordo it RIGHT
  • 140. thanks for attending
  • 141. time for a few Qs & hopefully few AsBlog: www.mehdi-khalili.comTwitter: @MehdiKhalili