Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Automated UI testing done right (DDDSydney)

21,487 views

Published on

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.

Published in: Technology

Automated UI testing done right (DDDSydney)

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

×