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 TestingDone Right
Mehdi KhaliliSenior Developer at ReadifyActive Open Source Projects:  • BDDfy  • Seleno  • HumanizerBlog: www.mehdi-khalil...
These practices are performed byprofessional developers and testers.Please DO try this at homeAuthorized and written by Me...
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
AgendaUI Testing: a likely failureFrom horrid to awesome in three stepsA few tipsQ&A
UI Testing!a likely failure   speaking of experience
a lot of teams      do  UI Testing
a lot of teamshave a great start at     UI Testing
theythen struggle with    UI Testing
and a lot of teams   then fail at    UI Testing
because   UI Tests are
because   UI Tests arehard to write
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 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
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
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
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
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?
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     D.R.Y.    your test
Page Object &Page Component    lead into    S.R.P.
proceduralduplicating logicduplicating selectorsmagic strings
… and 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
how do you getrequirementsfrom the business?
asked to work one a new feature or a bugprogrammer: “can I see the req. for this?”
feeling very proud for generatingthe most awesome requirements       BA: “here you go”
requirements book, anyone!?!
requirements in Word          === a lot of wasted time
requirements in Word           ===out of date requirements
requirements in Word          ===  a lot of confusion
requirements in Word         ===  misinterpretation
requirements in Word        ===   wrong product
BDD            to the rescuehttp://www.mehdi-khalili.com/bdd-to-the-rescue
BDD to the rescuereducing misinterpretation
BDD to the rescue    YAGNI
BDD to the rescueearly and frequent feedback
BDD to the rescuetest suite defined by BAs
BDD to the rescueliving documentation
write your UI Tests        based onacceptance criteria
use a BDD framework  to implement youracceptance criteria
use the  test results      as aprogress report
use the      test resultsto support and reduce    manual testing
computers are having fun while we are doing  the repetitive tasks they are built to do
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
thanks for attending
time for a few Qs                           &            hopefully few AsBlog:      www.mehdi-khalili.comTwitter:   @Mehdi...
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Upcoming SlideShare
Loading in …5
×

Automated UI Testing Done Right (QMSDNUG)

3,331 views

Published on

Published in: Technology

Automated UI Testing Done Right (QMSDNUG)

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

×