Your SlideShare is downloading. ×
Automated UI Testing Done Right (QMSDNUG)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Automated UI Testing Done Right (QMSDNUG)

2,296
views

Published on

Published in: Technology

3 Comments
4 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,296
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
22
Comments
3
Likes
4
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