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
Mehdi Khalili
Senior Developer at Readify

Active Open Source Projects:
  • BDDfy
  • Seleno
  • Humanizer

Blog: www.mehd...
These practices are performed by
professional developers and testers.

Please DO try this at home

Authorized and written ...
framework agnostic ideas and patterns
can apply these with any
UI and UI Testing framework
… but for this talk we are going to use
Selenium
an awesome automated UI testing
         framework
Selenium
   http://seleniumhq.org/projects/webdriver/




PM> Install-Package Selenium.WebDriver
BDDfy
A 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 write
Automated UI Tests
  the RIGHT way!
Seleno
  http://teststack.github.com/TestStack.Seleno/




PM> Install-Package TestStack.Seleno
samples are from Seleno
codebase and can be found at
 https://github.com/TestStack/TestStack.Seleno
In a nutshell


•   UI Testing: a likely failure
•   From horrid to awesome in three steps
•   A few tips (time permitting...
UI Testing!
a likely failure
speaking of
experience
a lot of teams
      do
  UI Testing
a lot of teams
have a “great start” at
      UI Testing
a lot of teams
then struggle with
    UI Testing
a lot of teams
  then fail at
   UI Testing
because   UI Tests are
because   UI Tests are
hard to maintain
because   UI Tests are
     brittle
but

  you can
mitigate
these issues
If you

 do it
RIGHT
test code
    is
  code
apply
S.R.P.
on your
code?
apply
S.R.P.
on your
tests
apply
D.R.Y.
on your
tests
care about your
tests as much as
you care about your
      code
or you will
waste a lot of time
or you will
   fail
from horrid to awesome
      in four three steps
a quick look
          at the sample

https://github.com/TestStack/TestStack.Seleno
guaranteed to
  fail
procedural
duplicated logic
duplicated selectors
magic strings
Step 1:




your tests with
 Page Object
Page Object
     brings


 OO to tests
a Page Object
 per page under test
a   link on the page
      becomes a
method on the
     Page Object
clicking a link on the page
turns into calling a method
     on the Page Object
instead of


you will get
textbox
     a
on the page becomes a
string property
 on the Page Object
filling a textbox on the
page turns into setting a
 string property on the
        Page Object
instead of


you will get
acheckbox
on the page becomes a
bool property
 on the Page Object
ticking a checkbox on the
 page turns into setting a
   bool property on the
       Page Object
anyaction
on the page becomes a
 method on the
     Page Object
… and you will get another
Page Object as the return
   value of the method
chain your calls
procedural
duplicating logic
duplicating selectors
magic strings
step 2:


    Page
 Components
Compose your Page Objects of
      smaller pieces
some pages are
some pages are

complex
remember

S.R.P.?
would you write



big    and   complex
 classes in your
    code?
care about your
        tests
    as much as
you care about your
        code
do NOT write


big   and complex
 Page Objects
use
Page Components
 to break
        down your
   Page Objects
use
Page Components
        for
panels      menus
       rows in grids
modal pop-ups
Page Components
      D.R.Y.
  your tests even more
instead of


you will get
and you can
compose other
  Page Objects
   using these
Page Components
Page Object &
Page Component
    lead into
    S.R.P.
Page Object &
Page Component
     D.R.Y.
    your test
... but
what about magic strings?
procedural
duplicating logic
duplicating selectors
magic strings
it is not
 only about
magic strings
the code is still
     ugly
step 3:




Strongly typed
 Page Object
you use
view models
 in your code
why not use
view models
in your tests?
(unofficial) step 4:


 Tests as Living
Documentation
write your UI Tests
        based on
acceptance criteria
use a BDD framework
  to implement your
acceptance criteria
use a BDD framework
 to turn your tests into
living documentation
use the
  test results
      as a
progress report
use the
  test results
as a support for
manual testing
A
few
tips
Do NOT use
Thread.Sleep
Thread.Sleep
  is slow
Thread.Sleep
 is brittle
often need to wait a bit
longer for things to load?
use implicit waits
need to wait longer
for specific elements to load?
use explicit waits
need to wait for an
AJAX call to finish?
use javascript
choose
right selectors
page structure
   changes
do
      NOT
     be fuzzy
with your selectors
do
         NOT
rely on the structure
    of your page
do
        NOT
    rely on the
surrounding elements
By.XPath("//ul[@id='album-list']/li[3]/a/span")



             you’re kidding, right?!
we use interfaces and
DI all over our code to
 make it unit testable
do what it takes to
support your tests
be explicit:
  add id on your
   elements to
support your tests
TARGET
your elements
   directly
     when possible
only one
   test
per action
do you have
workflows?
do one test per
 page/action
then do one test
 for entire flow
do NOT setup
 your required
state through UI
that will be
slow and brittle
setup your data
 through code
and navigate to
the page under
  test directly
use strongly typed
 actions for that
design by
interface!
  when you need it
do you support
multiple devices?
do you do
A/B testing?
create interface for
your Page Objects and
 use the interface in
   your test scripts
ISomePage



         A/B testing
PCPage                 iPadPage
           pages
… and use one
test script for all
 page variations
apply

YAGNI
  in your
test code
do

     NOT
      create a
    Page Object
until you need it
do

      NOT
   add an action to
     Page Object
until you need it
do

       NOT
   add a property to
     Page Object
until you need it
do

      NOT
   add a getter to
   your property
until you need it
run and maintain
     your tests
run
  your tests
frequently
fix
  the broken test right

when 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 a
waste of time
so
do NOT do it
     or
do it RIGHT
when   Done Right it is
 well worth it
thanks for
 attending
time for a few Qs
                                  &
                   hopefully few As

Blog:            www.mehdi-khal...
With thanks to our sponsors
Please complete your feedback
  forms, and return them to the
registration desk for a chance
                       to win...
Automated UI testing done right (DDDSydney)
Automated UI testing done right (DDDSydney)
Automated UI testing done right (DDDSydney)
Automated UI testing done right (DDDSydney)
Automated UI testing done right (DDDSydney)
Automated UI testing done right (DDDSydney)
Automated UI testing done right (DDDSydney)
Automated UI testing done right (DDDSydney)
Automated UI testing done right (DDDSydney)
Upcoming SlideShare
Loading in …5
×

of

Automated UI testing done right (DDDSydney) Slide 1 Automated UI testing done right (DDDSydney) Slide 2 Automated UI testing done right (DDDSydney) Slide 3 Automated UI testing done right (DDDSydney) Slide 4 Automated UI testing done right (DDDSydney) Slide 5 Automated UI testing done right (DDDSydney) Slide 6 Automated UI testing done right (DDDSydney) Slide 7 Automated UI testing done right (DDDSydney) Slide 8 Automated UI testing done right (DDDSydney) Slide 9 Automated UI testing done right (DDDSydney) Slide 10 Automated UI testing done right (DDDSydney) Slide 11 Automated UI testing done right (DDDSydney) Slide 12 Automated UI testing done right (DDDSydney) Slide 13 Automated UI testing done right (DDDSydney) Slide 14 Automated UI testing done right (DDDSydney) Slide 15 Automated UI testing done right (DDDSydney) Slide 16 Automated UI testing done right (DDDSydney) Slide 17 Automated UI testing done right (DDDSydney) Slide 18 Automated UI testing done right (DDDSydney) Slide 19 Automated UI testing done right (DDDSydney) Slide 20 Automated UI testing done right (DDDSydney) Slide 21 Automated UI testing done right (DDDSydney) Slide 22 Automated UI testing done right (DDDSydney) Slide 23 Automated UI testing done right (DDDSydney) Slide 24 Automated UI testing done right (DDDSydney) Slide 25 Automated UI testing done right (DDDSydney) Slide 26 Automated UI testing done right (DDDSydney) Slide 27 Automated UI testing done right (DDDSydney) Slide 28 Automated UI testing done right (DDDSydney) Slide 29 Automated UI testing done right (DDDSydney) Slide 30 Automated UI testing done right (DDDSydney) Slide 31 Automated UI testing done right (DDDSydney) Slide 32 Automated UI testing done right (DDDSydney) Slide 33 Automated UI testing done right (DDDSydney) Slide 34 Automated UI testing done right (DDDSydney) Slide 35 Automated UI testing done right (DDDSydney) Slide 36 Automated UI testing done right (DDDSydney) Slide 37 Automated UI testing done right (DDDSydney) Slide 38 Automated UI testing done right (DDDSydney) Slide 39 Automated UI testing done right (DDDSydney) Slide 40 Automated UI testing done right (DDDSydney) Slide 41 Automated UI testing done right (DDDSydney) Slide 42 Automated UI testing done right (DDDSydney) Slide 43 Automated UI testing done right (DDDSydney) Slide 44 Automated UI testing done right (DDDSydney) Slide 45 Automated UI testing done right (DDDSydney) Slide 46 Automated UI testing done right (DDDSydney) Slide 47 Automated UI testing done right (DDDSydney) Slide 48 Automated UI testing done right (DDDSydney) Slide 49 Automated UI testing done right (DDDSydney) Slide 50 Automated UI testing done right (DDDSydney) Slide 51 Automated UI testing done right (DDDSydney) Slide 52 Automated UI testing done right (DDDSydney) Slide 53 Automated UI testing done right (DDDSydney) Slide 54 Automated UI testing done right (DDDSydney) Slide 55 Automated UI testing done right (DDDSydney) Slide 56 Automated UI testing done right (DDDSydney) Slide 57 Automated UI testing done right (DDDSydney) Slide 58 Automated UI testing done right (DDDSydney) Slide 59 Automated UI testing done right (DDDSydney) Slide 60 Automated UI testing done right (DDDSydney) Slide 61 Automated UI testing done right (DDDSydney) Slide 62 Automated UI testing done right (DDDSydney) Slide 63 Automated UI testing done right (DDDSydney) Slide 64 Automated UI testing done right (DDDSydney) Slide 65 Automated UI testing done right (DDDSydney) Slide 66 Automated UI testing done right (DDDSydney) Slide 67 Automated UI testing done right (DDDSydney) Slide 68 Automated UI testing done right (DDDSydney) Slide 69 Automated UI testing done right (DDDSydney) Slide 70 Automated UI testing done right (DDDSydney) Slide 71 Automated UI testing done right (DDDSydney) Slide 72 Automated UI testing done right (DDDSydney) Slide 73 Automated UI testing done right (DDDSydney) Slide 74 Automated UI testing done right (DDDSydney) Slide 75 Automated UI testing done right (DDDSydney) Slide 76 Automated UI testing done right (DDDSydney) Slide 77 Automated UI testing done right (DDDSydney) Slide 78 Automated UI testing done right (DDDSydney) Slide 79 Automated UI testing done right (DDDSydney) Slide 80 Automated UI testing done right (DDDSydney) Slide 81 Automated UI testing done right (DDDSydney) Slide 82 Automated UI testing done right (DDDSydney) Slide 83 Automated UI testing done right (DDDSydney) Slide 84 Automated UI testing done right (DDDSydney) Slide 85 Automated UI testing done right (DDDSydney) Slide 86 Automated UI testing done right (DDDSydney) Slide 87 Automated UI testing done right (DDDSydney) Slide 88 Automated UI testing done right (DDDSydney) Slide 89 Automated UI testing done right (DDDSydney) Slide 90 Automated UI testing done right (DDDSydney) Slide 91 Automated UI testing done right (DDDSydney) Slide 92 Automated UI testing done right (DDDSydney) Slide 93 Automated UI testing done right (DDDSydney) Slide 94 Automated UI testing done right (DDDSydney) Slide 95 Automated UI testing done right (DDDSydney) Slide 96 Automated UI testing done right (DDDSydney) Slide 97 Automated UI testing done right (DDDSydney) Slide 98 Automated UI testing done right (DDDSydney) Slide 99 Automated UI testing done right (DDDSydney) Slide 100 Automated UI testing done right (DDDSydney) Slide 101 Automated UI testing done right (DDDSydney) Slide 102 Automated UI testing done right (DDDSydney) Slide 103 Automated UI testing done right (DDDSydney) Slide 104 Automated UI testing done right (DDDSydney) Slide 105 Automated UI testing done right (DDDSydney) Slide 106 Automated UI testing done right (DDDSydney) Slide 107 Automated UI testing done right (DDDSydney) Slide 108 Automated UI testing done right (DDDSydney) Slide 109 Automated UI testing done right (DDDSydney) Slide 110 Automated UI testing done right (DDDSydney) Slide 111 Automated UI testing done right (DDDSydney) Slide 112 Automated UI testing done right (DDDSydney) Slide 113 Automated UI testing done right (DDDSydney) Slide 114 Automated UI testing done right (DDDSydney) Slide 115 Automated UI testing done right (DDDSydney) Slide 116 Automated UI testing done right (DDDSydney) Slide 117 Automated UI testing done right (DDDSydney) Slide 118 Automated UI testing done right (DDDSydney) Slide 119 Automated UI testing done right (DDDSydney) Slide 120 Automated UI testing done right (DDDSydney) Slide 121 Automated UI testing done right (DDDSydney) Slide 122 Automated UI testing done right (DDDSydney) Slide 123 Automated UI testing done right (DDDSydney) Slide 124 Automated UI testing done right (DDDSydney) Slide 125 Automated UI testing done right (DDDSydney) Slide 126 Automated UI testing done right (DDDSydney) Slide 127 Automated UI testing done right (DDDSydney) Slide 128 Automated UI testing done right (DDDSydney) Slide 129 Automated UI testing done right (DDDSydney) Slide 130 Automated UI testing done right (DDDSydney) Slide 131 Automated UI testing done right (DDDSydney) Slide 132 Automated UI testing done right (DDDSydney) Slide 133 Automated UI testing done right (DDDSydney) Slide 134 Automated UI testing done right (DDDSydney) Slide 135 Automated UI testing done right (DDDSydney) Slide 136 Automated UI testing done right (DDDSydney) Slide 137 Automated UI testing done right (DDDSydney) Slide 138 Automated UI testing done right (DDDSydney) Slide 139 Automated UI testing done right (DDDSydney) Slide 140 Automated UI testing done right (DDDSydney) Slide 141 Automated UI testing done right (DDDSydney) Slide 142 Automated UI testing done right (DDDSydney) Slide 143
Upcoming SlideShare
Microservices lessons from trenches
Next
Download to read offline and view in fullscreen.

7 Likes

Share

Download to read offline

Automated UI testing done right (DDDSydney)

Download to read offline

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.

Related Books

Free with a 30 day trial from Scribd

See all

Automated UI testing done right (DDDSydney)

  1. 1. Automated UI Testing Done Right
  2. 2. Mehdi Khalili Senior Developer at Readify Active Open Source Projects: • BDDfy • Seleno • Humanizer Blog: www.mehdi-khalili.com Twitter: @MehdiKhalili
  3. 3. These practices are performed by professional developers and testers. Please DO try this at home Authorized and written by Mehdi Khalili
  4. 4. framework agnostic ideas and patterns
  5. 5. can apply these with any UI and UI Testing framework
  6. 6. … but for this talk we are going to use
  7. 7. Selenium an awesome automated UI testing framework
  8. 8. Selenium http://seleniumhq.org/projects/webdriver/ PM> Install-Package Selenium.WebDriver
  9. 9. BDDfy A 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 write Automated UI Tests the RIGHT way!
  12. 12. Seleno http://teststack.github.com/TestStack.Seleno/ PM> Install-Package TestStack.Seleno
  13. 13. samples are from Seleno codebase 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 of experience
  17. 17. a lot of teams do UI Testing
  18. 18. a lot of teams have a “great start” at UI Testing
  19. 19. a lot of teams then 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 are hard to maintain
  23. 23. because UI Tests are brittle
  24. 24. but you can mitigate these issues
  25. 25. If you do it RIGHT
  26. 26. test code is code
  27. 27. apply S.R.P. on your code?
  28. 28. apply S.R.P. on your tests
  29. 29. apply D.R.Y. on your tests
  30. 30. care about your tests as much as you care about your code
  31. 31. or you will waste 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 sample https://github.com/TestStack/TestStack.Seleno
  35. 35. guaranteed to fail
  36. 36. procedural duplicated logic duplicated selectors magic 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 a method on the Page Object
  41. 41. clicking a link on the page turns into calling a method on the Page Object
  42. 42. instead of you will get
  43. 43. textbox a on the page becomes a string property on the Page Object
  44. 44. filling a textbox on the page turns into setting a string property on the Page Object
  45. 45. instead of you will get
  46. 46. acheckbox on the page becomes a bool 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. anyaction on the page becomes a method on the Page Object
  49. 49. … and you will get another Page Object as the return value of the method
  50. 50. chain your calls
  51. 51. procedural duplicating logic duplicating selectors magic strings
  52. 52. step 2: Page Components Compose your Page Objects of smaller pieces
  53. 53. some pages are
  54. 54. some pages are complex
  55. 55. remember S.R.P.?
  56. 56. would you write big and complex classes in your code?
  57. 57. care about your tests as much as you care about your code
  58. 58. do NOT write big and complex Page Objects
  59. 59. use Page Components to break down your Page Objects
  60. 60. use Page Components for panels menus rows in grids modal pop-ups
  61. 61. Page Components D.R.Y. your tests even more
  62. 62. instead of you will get
  63. 63. and you can compose other Page Objects using these Page 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. procedural duplicating logic duplicating selectors magic strings
  69. 69. it is not only about magic strings
  70. 70. the code is still ugly
  71. 71. step 3: Strongly typed Page Object
  72. 72. you use view models in your code
  73. 73. why not use view models in your tests?
  74. 74. (unofficial) step 4: Tests as Living Documentation
  75. 75. write your UI Tests based on acceptance criteria
  76. 76. use a BDD framework to implement your acceptance criteria
  77. 77. use a BDD framework to turn your tests into living documentation
  78. 78. use the test results as a progress report
  79. 79. use the test results as a support for manual testing
  80. 80. A few tips
  81. 81. Do NOT use Thread.Sleep
  82. 82. Thread.Sleep is slow
  83. 83. Thread.Sleep is brittle
  84. 84. often need to wait a bit longer for things to load?
  85. 85. use implicit waits
  86. 86. need to wait longer for specific elements to load?
  87. 87. use explicit waits
  88. 88. need to wait for an AJAX call to finish?
  89. 89. use javascript
  90. 90. choose right selectors
  91. 91. page structure changes
  92. 92. do NOT be fuzzy with your selectors
  93. 93. do NOT rely on the structure of your page
  94. 94. do NOT rely on the surrounding elements
  95. 95. By.XPath("//ul[@id='album-list']/li[3]/a/span") you’re kidding, right?!
  96. 96. we use interfaces and DI all over our code to make it unit testable
  97. 97. do what it takes to support your tests
  98. 98. be explicit: add id on your elements to support your tests
  99. 99. TARGET your elements directly when possible
  100. 100. only one test per action
  101. 101. do you have workflows?
  102. 102. do one test per page/action
  103. 103. then do one test for entire flow
  104. 104. do NOT setup your required state through UI
  105. 105. that will be slow and brittle
  106. 106. setup your data through code
  107. 107. and navigate to the page under test directly
  108. 108. use strongly typed actions for that
  109. 109. design by interface! when you need it
  110. 110. do you support multiple devices?
  111. 111. do you do A/B testing?
  112. 112. create interface for your Page Objects and use the interface in your test scripts
  113. 113. ISomePage A/B testing PCPage iPadPage pages
  114. 114. … and use one test script for all page variations
  115. 115. apply YAGNI in your test code
  116. 116. do NOT create a Page Object until you need it
  117. 117. do NOT add an action to Page Object until you need it
  118. 118. do NOT add a property to Page Object until you need it
  119. 119. do NOT add a getter to your property until you need it
  120. 120. run and maintain your tests
  121. 121. run your tests frequently
  122. 122. fix the broken test right when 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 a waste of time
  129. 129. so do NOT do it or do 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 As Blog: www.mehdi-khalili.com Twitter: @MehdiKhalili http://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 the registration desk for a chance to win a Nokia Lumia
  • powerirs

    Jun. 23, 2017
  • mpausch

    Mar. 20, 2017
  • JosephOrtiz7

    Aug. 16, 2016
  • OmayerHabi

    Jan. 7, 2016
  • LukeGordon5

    Nov. 2, 2015
  • brunofig

    Sep. 17, 2015
  • ZeinabHamze

    Jul. 29, 2015

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.

Views

Total views

21,840

On Slideshare

0

From embeds

0

Number of embeds

16,595

Actions

Downloads

79

Shares

0

Comments

0

Likes

7

×