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.

1. Automated
UI Testing
Done Right

2. Mehdi Khalili
Senior Developer at Readify
Active Open Source Projects:
• BDDfy
• Seleno
• Humanizer
Blog: www.mehdi-khalili.com
Twitter: @MehdiKhalili

3. These practices are performed by
professional developers and testers.
Please DO try this at home
Authorized and written by Mehdi Khalili

4. framework agnostic ideas and patterns

5. can apply these with any
UI and UI Testing framework

6. … but for this talk we are going to use

7. Selenium
an awesome automated UI testing
framework

8. Selenium
http://seleniumhq.org/projects/webdriver/
PM> Install-Package Selenium.WebDriver

9. BDDfy
A 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 write
Automated UI Tests
the RIGHT way!

12. Seleno
http://teststack.github.com/TestStack.Seleno/
PM> Install-Package TestStack.Seleno

13. samples are from Seleno
codebase and can be found at
https://github.com/TestStack/TestStack.Seleno

14. In a nutshell
• UI Testing: a likely failure
• From horrid to awesome in three steps
• A few tips (time permitting)
• Q&A

15. UI Testing!
a likely failure

16. speaking of
experience

17. a lot of teams
do
UI Testing

18. a lot of teams
have a “great start” at
UI Testing

19. a lot of teams
then struggle with
UI Testing

20. a lot of teams
then fail at
UI Testing

21. because UI Tests are

22. because UI Tests are
hard to maintain

23. because UI Tests are
brittle

24. but
you can
mitigate
these issues

25. If you
do it
RIGHT

26. test code
is
code

27. apply
S.R.P.
on your
code?

28. apply
S.R.P.
on your
tests

29. apply
D.R.Y.
on your
tests

30. care about your
tests as much as
you care about your
code

31. or you will
waste a lot of time

32. or you will
fail

33. from horrid to awesome
in four three steps

34. a quick look
at the sample
https://github.com/TestStack/TestStack.Seleno

35. guaranteed to
fail

37. procedural
duplicated logic
duplicated selectors
magic strings

38. Step 1:
your tests with
Page Object

39. Page Object
brings
OO to tests

40. a Page Object
per page under test

41. a link on the page
becomes a
method on the
Page Object

42. clicking a link on the page
turns into calling a method
on the Page Object

43. instead of
you will get

44. textbox
a
on the page becomes a
string property
on the Page Object

45. filling a textbox on the
page turns into setting a
string property on the
Page Object

46. instead of
you will get

47. acheckbox
on the page becomes a
bool property
on the Page Object

48. ticking a checkbox on the
page turns into setting a
bool property on the
Page Object

49. anyaction
on the page becomes a
method on the
Page Object

50. … and you will get another
Page Object as the return
value of the method

51. chain your calls

53. procedural
duplicating logic
duplicating selectors
magic strings

54. step 2:
Page
Components
Compose your Page Objects of
smaller pieces

55. some pages are

56. some pages are
complex

57. remember
S.R.P.?

58. would you write
big and complex
classes in your
code?

59. care about your
tests
as much as
you care about your
code

60. do NOT write
big and complex
Page Objects

61. use
Page Components
to break
down your
Page Objects

62. use
Page Components
for
panels menus
rows in grids
modal pop-ups

63. Page Components
D.R.Y.
your tests even more

64. instead of
you will get

65. and you can
compose other
Page Objects
using these
Page Components

67. Page Object &
Page Component
lead into
S.R.P.

68. Page Object &
Page Component
D.R.Y.
your test

69. ... but

70. what about magic strings?

71. procedural
duplicating logic
duplicating selectors
magic strings

73. it is not
only about
magic strings

74. the code is still
ugly

77. step 3:
Strongly typed
Page Object

78. you use
view models
in your code

80. why not use
view models
in your tests?

82. (unofficial) step 4:
Tests as Living
Documentation

83. write your UI Tests
based on
acceptance criteria

84. use a BDD framework
to implement your
acceptance criteria

85. use a BDD framework
to turn your tests into
living documentation

87. use the
test results
as a
progress report

88. use the
test results
as a support for
manual testing

89. A
few
tips

90. Do NOT use
Thread.Sleep

91. Thread.Sleep
is slow

92. Thread.Sleep
is brittle

93. often need to wait a bit
longer for things to load?

94. use implicit waits

95. need to wait longer
for specific elements to load?

96. use explicit waits

97. need to wait for an
AJAX call to finish?

98. use javascript

99. choose
right selectors

100. page structure
changes

101. do
NOT
be fuzzy
with your selectors

102. do
NOT
rely on the structure
of your page

103. do
NOT
rely on the
surrounding elements

104. By.XPath("//ul[@id='album-list']/li[3]/a/span")
you’re kidding, right?!

105. we use interfaces and
DI all over our code to
make it unit testable

106. do what it takes to
support your tests

107. be explicit:
add id on your
elements to
support your tests

108. TARGET
your elements
directly
when possible

109. only one
test
per action

110. do you have
workflows?

111. do one test per
page/action

112. then do one test
for entire flow

113. do NOT setup
your required
state through UI

114. that will be
slow and brittle

115. setup your data
through code

116. and navigate to
the page under
test directly

117. use strongly typed
actions for that

118. design by
interface!
when you need it

119. do you support
multiple devices?

120. do you do
A/B testing?

121. create interface for
your Page Objects and
use the interface in
your test scripts

122. ISomePage
A/B testing
PCPage iPadPage
pages

123. … and use one
test script for all
page variations

124. apply
YAGNI
in your
test code

125. do
NOT
create a
Page Object
until you need it

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

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

128. do
NOT
add a getter to
your property
until you need it

129. run and maintain
your tests

130. run
your tests
frequently

131. fix
the broken test right
when it breaks

132. tests you
do not run
===
broken tests

133. broken tests you
do not fix
===
ignored tests

134. … and finally

135. Confucius says …

136. UI Testing
is hard

137. and could be a
waste of time

138. so
do NOT do it
or
do it RIGHT

139. when Done Right it is
well worth it

140. thanks for
attending

141. 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

142. With thanks to our sponsors

143. Please complete your feedback
forms, and return them to the
registration desk for a chance
to win a
Nokia Lumia