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,176 views

Published on

Published in: Technology
3 Comments
4 Likes
Statistics
Notes
No Downloads
Views
Total views
3,176
On SlideShare
0
From Embeds
0
Number of Embeds
1,621
Actions
Shares
0
Downloads
35
Comments
3
Likes
4
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
  • 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 (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

    ×