The document discusses unit testing anti-patterns. It describes implementation anti-patterns like long tests with many assertions, long test files, tests with complex logic, slow tests, and tests that cannot fail. It also describes workflow anti-patterns like writing tests last, only testing for regression, testing elsewhere than in unit tests, only running tests from the command line, and not using continuous integration. It suggests approaches like writing independent tests, avoiding redundant tests, and testing frequently to avoid these anti-patterns.

2. aninda kundu
spacefugitive @aninda42

7. 2008

8. 

9. sidu ponnappa
kaiwren @ponnappa

10. 2006

12. any_instance

13. any_instance
that’s right - it’s an antipattern

14. wrest

15. wrest
'http://google.com'.to_uri(:follow_redirects => false).get

16. started two companies

17. started two companies
over five years

20. 

21. { context }

23. pair programming

24. stand-ups

25. TDD

26. { facts }

29. O SHIT!

30. feedback!

33. changing code is tough
+
feedback loops should be short

34. { tests! }

36. no, not those

37. yeah, those

38. choices!

39. watir?
TDD?
functional?
cucumber?
rspec?
BDD?
minitest?
shoulda?
integration? regression?
unit?

40. full-to confusion for beginners

41. still a little confusing for the experienced

42. a good place to start?

43. a good place to start?
unit tests

44. this talk is about unit testing
cukes, capybara, selenium et. al. are out of scope

45. we also thought...

46. lets analyse the situation by looking at the villains

47. after all, a good villain is a sexy thang!

48. after all, a good villain is a sexy thang!
makes you want to be the hero

49. like this guy

50. so this talk is about unit testing anti-patterns

51. { two types }

52. two types
just for this talk, yeah? not formal, like.

53. implementation / workflow

54. implementation / workflow
what’s in the test / how it was written

55. { implementation anti-patterns }

56. The long test
The test with too many assertions

57. The long test file

59. The long test file

60. The long test file
Refactor: extract multiple classes

61. The test that has logic

65. who watches the watchmen?

66. The implementation bound test

68. the test with arcane terminology

69. the test with arcane terminology
name/descriptor should say it all

70. the test with arcane terminology
name/descriptor should say it all
treat these as developer documentation

71. the test with arcane terminology
name/descriptor should say it all
treat these as developer documentation
people rolling onto a project <3 you for it

72. the test with arcane terminology
name/descriptor should say it all
treat these as developer documentation
people rolling onto a project <3 you for it
comment = well named test

73. The slow test

74. the slow test
too much data ? (again, fixtures or heavy setup)

75. The slow test
too much data ? (again, fixtures or heavy setup)
up next..

76. The slow test
too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)

77. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix

78. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix
Testing externals?

79. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix
Testing externals?
Stop it! Stub it!

80. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix
Testing externals?
Stop it! Stub it!
Rails startup time !@#$?

81. The slow test
Too much data ? (again, fixtures or heavy setup)
up next..
Too many objects (running into MRI GC?)
profile and fix
Testing externals?
Stop it! Stub it!
Rails startup time !@#$?
Spork, Guard

82. The test that has complex setup

83. The test that has complex setup
Fixtures are for static data only

84. The test that has complex setup
Fixtures are for static data only
Large factory setups are better than invisible fixtures

85. The test that has complex setup
Fixtures are for static data only
Large factory setups are better than invisible fixtures
Stub non essential factories

88. All tests should execute independantly as well as a suite

89. All tests should execute independantly as well as a suite
tests must not share state

90. Avoid redundant / replicated tests

91. Avoid redundant / replicated tests
Push tests down the order as much as possible
e.g. Controller tests that can exist as model tests
Rule of thumb : Do this as long as you can keep the
name of the test almost the same

92. The test that shows high churn

93. The test that cannot fail
Red-green refactor. Make sure the test fails first.

94. { workflow anti-patterns }

95. TEST LAST

96. #1

99. refactor

100. #1.1

103. b692246bad

104. refactor
b692246bad

105. refactor
b692246bad 0df4e19f2a

106. TESTING ONLY FOR
REGRESSION

107. usually test last

108. TDD helps encapsulate

109. TESTING ELSWHERE

110. separate teams of testers writing unit tests

111. ONLY RUN RAKE

112. means you’re never working on just one unit

113. NEVER RUN RAKE

114. without CI you’re in a world of pain

115. ONLY RUN TEST(S) FROM CLI

116. slower, less productive

117. QA TEAM FOR BUSINESS LOGIC
VERIFICATION

118. your tests should be enough

119. NO CI

120. test frequently (every commit!)

121. feedback for distributed/large teams

122. CI servers are collaboration tools

123. MANUAL DEPLOY TO STAGING

124. don’t trust your commits

125. { reading
between the
lines }

126. text
subtext

128. we do BDD, not TDD

129. we do BDD, not TDD
we only write Cukes

130. we have 100% code coverage

131. we have 100% code coverage
that’s from all those Cukes we just told you about

132. we love our tests
we run them at least once every day

133. we keep our build green

134. we keep our build green
we comment out failing tests if that’s what it takes

135. tests are an integral part of the
way we work

136. tests are an integral part of the
way we work
we write them for every client that wants them

137. Attributions
•Agile Pills: http://briannoyle.wordpress.com/2009/05/12/getting-yer-agile-on-at-a-discount-upcoming-course
•TDD index card: http://www.testically.org/2011/01/12/the-ideal-use-case-to-give-tdd-a-try/
•Pair programming: http://thoughtworker.com/agile-our-way-life
•Stand-up: http://www.flickr.com/photos/karthikc/333796551/
•C# : http://www.jameswiseman.com/blog/tag/c-sharp/
•Robotic arm : http://profmason.com/?p=562
•Wrecking ball: http://marilebetterdays.wordpress.com/2012/02/28/wrecking-ball-lyrics-the-title-track/
•Cat eat finger: http://www.123rf.com/photo_2005824_cat-eating-human-finger.html
•Tiger attack: http://tvmywifewatches.blogspot.com/2011/07/rhw-of-nj-pointcounterpoint-should-kim.html
•Lex Luthor: http://maxnaylor.ca/?attachment_id=835
•The Joker: http://www.fanpop.com/spots/the-joker/images/9028188/title/joker

138. 42
@ponnappa @aninda42
