Automated UI testing done right (DDDSydney)

20,377 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
2 Comments
7 Likes
Statistics
Notes
No Downloads
Views
Total views
20,377
On SlideShare
0
From Embeds
0
Number of Embeds
15,753
Actions
Shares
0
Downloads
69
Comments
2
Likes
7
Embeds 0
No embeds

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

    ×