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
Email: me@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

10. BDDfy
A simple BDD framework to use and extend!
BDDfy turns your traditional unit tests
into BDD behaviours

11. BDDfy
http://teststack.github.com/TestStack.BDDfy/
PM> Install-Package TestStack.BDDfy

12. Seleno
helps you write
Automated UI Tests
the RIGHT way!

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

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

15. Agenda
UI Testing: a likely failure
From horrid to awesome in three steps
A few tips
Q&A

16. UI Testing!
a likely failure
speaking of experience

17. a lot of teams
do
UI Testing

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

20. they
then struggle with
UI Testing

21. and a lot of teams
then fail at
UI Testing

22. because UI Tests are

23. because UI Tests are
hard to write

24. because UI Tests are
hard to maintain

25. because UI Tests are
brittle

26. but
you can
mitigate
these issues

27. If you
do it
RIGHT

28. test code
is
code

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

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

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

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

33. or you will
waste a lot of time

34. or you will
fail

35. from horrid to awesome
in three steps

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

37. guaranteed to
fail

39. procedural
duplicated logic
duplicated selectors
magic strings

40. Step 1:
your tests with
Page Object

41. Page Object
brings
OO to tests

42. a Page Object
per page under test

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

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

45. instead of
you will get

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

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

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

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

50. instead of
you will get

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

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

53. chain your calls

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

56. some pages are

57. some pages are
complex

58. remember
S.R.P.?

59. would you write
big and complex
classes in 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
D.R.Y.
your test

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

69. procedural
duplicating logic
duplicating selectors
magic strings

71. … and the code is still
ugly

74. step 3:
Strongly typed
Page Object

75. you use
view models
in your code

79. why not use
view models
in your tests?

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

82. how do you get
requirements
from the business?

83. asked to work one a new feature or a bug
programmer: “can I see the req. for this?”

84. feeling very proud for generating
the most awesome requirements
BA: “here you go”

85. requirements book, anyone!?!

86. requirements in Word
===
a lot of wasted time

87. requirements in Word
===
out of date requirements

88. requirements in Word
===
a lot of confusion

89. requirements in Word
===
misinterpretation

90. requirements in Word
===
wrong product

91. BDD
to the rescue
http://www.mehdi-khalili.com/bdd-to-the-rescue

92. BDD to the rescue
reducing misinterpretation

93. BDD to the rescue
YAGNI

94. BDD to the rescue
early and frequent feedback

95. BDD to the rescue
test suite defined by BAs

96. BDD to the rescue
living documentation

97. write your UI Tests
based on
acceptance criteria

98. use a BDD framework
to implement your
acceptance criteria

100. use the
test results
as a
progress report

101. use the
test results
to support and reduce
manual testing

102. computers are having fun while we are doing
the repetitive tasks they are built to do

103. A
few
tips

104. Do NOT use
Thread.Sleep

105. Thread.Sleep
is slow

106. Thread.Sleep
is brittle

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

108. use implicit waits

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

110. use explicit waits

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

112. use javascript

113. choose
right selectors

114. page structure
changes

115. do
NOT
be fuzzy
with your selectors

116. do
NOT
rely on the structure
of your page

117. do
NOT
rely on the
surrounding elements

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

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

120. do what it takes to
support your tests

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

122. TARGET
your elements
directly
when possible

123. only one
test
per action

124. do you have
workflows?

125. do one test per
page/action

126. then do one test
for entire flow

127. do NOT setup
your required
state through UI

128. that will be
slow and brittle

129. setup your data
through code

130. and navigate to
the page under
test directly

131. use strongly typed
actions for that

132. design by
interface!
when you need it

133. do you support
multiple devices?

134. do you do
A/B testing?

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

136. ISomePage
A/B testing
PCPage iPadPage
pages

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

138. apply
YAGNI
in your
test code

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

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

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

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

143. run and maintain
your tests

144. run
your tests
frequently

145. fix
the broken test right
when it breaks

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

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

148. … and finally

149. Confucius says …

150. UI Testing
is hard

151. and could be a
waste of time

152. so
do NOT do it
or
do it RIGHT

153. thanks for
attending

154. time for a few Qs
&
hopefully few As
Blog: www.mehdi-khalili.com
Twitter: @MehdiKhalili