The document discusses lessons learned from testing code. It notes that test code should be simpler with lower complexity than the code being tested. Duplication in tests often indicates a missing abstraction, and repetition can suggest the same. Both the code and tests evolve together through iterations. Writing tests first aids specification, while testing later often serves debugging.

1. Lessons from Testing
examples taken
from
http://cyber-dojo.org
@JonJagger
jon@jaggersoft.com
1

2. Avoid unnecessary
burning of calories!
2

3. FizzBuzz
3

4. what do I notice?
E09E8C snake 4

5. 5

6. Suppose we measure
the average cyclomatic
complexity of the code
under test and the test
code.
6

7. Higher number
means more
complex.
7

8. tests code
3.7 > 2.1
8

9. tests code
3.7 2.1
9
tests
tests
4.3 > >

10. NO!tests code
4.3> 3.7 >
2.1
10
tests
tests

11. tests code
2.1 == 2.1
11

12. NO!
tests code
2.1 == 2.1 12

13. tests code
2.0 < 2.1
13

14. NO!
tests code
2.0 < 2.1 14

15. code
tests
1.0 <<<
2.1
15

16. YEScode
tests
1.0 <<<
2.1
16

17. 1.0 ~> Simple
E09E8C wolf 17

18. what do I notice most?
18

19. Duplication!
19

20. Duplication
usually indicates
a missing
abstraction
20

21. what do I notice now?
21

22. Duplication!
22

23. 23

24. what do I notice now?
24

25. Duplication!
25

26. 26

27. what do I notice now?
27

28. missing examples?
28

29. 29

30. what do I notice now?
30

31. better test names?
31

32. 32

33. what do I notice now?
33

34. different_identifier_style?
differentIdentifierStyle?
34

35. that's ok!
35

36. what do I notice now?
36

37. duplication?
37

38. this is worse!
38

39. how about this?
39

40. 40

41. 41
1.0
Specific ?
21F1F3 alligator

42. ! 21F1F3 alligator
42

43. Specific ?
43

44. Specific :-)
44

45. Repetition ?
45
?

46. Repetition can
indicate a missing
abstraction
46

47. Specific
47

48. Specific
48

49. 49

50. Recently Used List
50

51. e.g. Recent Files...
51

52. what do I notice?
DE3BF3 buffalo 52

53. Duplication!
53

54. What's left?
red WTF?
blue
54

55. e.g. Files!
55

56. better!
BAC947 snake 56

57. better still
57

58. What do I notice now?
58

59. Duplication!
59

60. What does
assertEquals()
print when it fails?
60

61. 61

62. Do your
diagnostics
diagnose?
62

63. What
diagnostic
do you want?
63

64. How about this?
64

65. Make it so!
65

66. 66

67. 67
A
B C
D E F
G
external external

68. 68
A
B C
tA
mockist style
B' C'
D E F
G

69. mockist style
69
A
B C
D E F
G
tB
D' E'
C'

70. mockist style
70
A
B C
D E F
G
G'
F'
B'
tC

71. mockist style
code tests
71

72. classic style
72
A
B C
tA
D E F
G
D' F'

73. classic style
code tests
73

74. the.law.of.demeter
74

75. 75

76. which is more
important?
the code or the
tests?
76

77. both
77

78. You cannot determine
the character or
nature of a system
within itself.
Attempts to do so
lead to confusion
and disorder.
78

79. code and tests
co-evolve
79

80. evolution is always
co-evolution
80

81. 81

82. 82

83. 83
testing
time

84. 84
debugging
time

85. debugging = removing
what you don't want
85

86. if you get rid of
what you don't want,
will you be left with
what you do want?
86

87. if you get rid of
what you ?
don't want,
will you be left with
what you do want? 87

88. 88
testing
time

89. 89
specification
time

90. 90
specific.........
time

91. Summary
Burning calories - a metaphor for understandability
Tests should be simple, linear, low complexity
Tests should be specific
Long_specific_test_names_is_ok
Duplication usually means a missing abstraction
Repetition can indicate a missing abstraction too
Do your diagnostics diagnose? custom assertions
Don't cheat on test data - "String1" vs "red"
Overuse Mockist style and you will regret it
Code and tests co-evolve
Test at the end is often debugging
Test at the beginning as specification
91

92. 92

93. 93

94. 94

95. 95

96. code with no tests
96
FB75B3

97. 97

98. Lesson ONE
test code must be much
simpler than the code it
tests
98