lessons from testing

Lessons from Testing
examples taken
from
http://cyber-dojo.org
@JonJagger
jon@jaggersoft.com
1
Thursday, 23 October 14

Avoid unnecessary
burning of calories!
2

FizzBuzz
3

what do I notice?
E09E8C snake 4

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

Higher number
means more
complex.
7

tests code
3.7 > 2.1
8

tests code
3.7 2.1
9
tests
tests
4.3 > >

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

tests code
2.1 == 2.1
11

NO!
tests code
2.1 == 2.1 12

tests code
2.0 < 2.1
13

NO!
tests code
2.0 < 2.1 14

code
tests
1.0 <<<
2.1
15

YEScode
tests
1.0 <<<
2.1
16

1.0 ~> Simple
E09E8C wolf 17

what do I notice most?
18

Duplication!
19

Duplication
usually indicates
a missing
abstraction
20

what do I notice now?
21

Duplication!
22

24

Duplication!
25

27

missing examples?
28

30

better test names?
31

33

different_identifier_style?
differentIdentifierStyle?
34

that's ok!
35

36

duplication?
37

this is worse!
38

how about this?
39

41
1.0
Specific ?
21F1F3 alligator

42
!

Specific ?
43

Specific :-)
44

Repetition ?
45
?

Repetition can
indicate a missing
abstraction
46

Specific
47

Specific
48

Recently Used List
50

e.g. Recent Files...
51

what do I notice?
DE3BF3 buffalo 52

Duplication!
53

What's left?
red WTF?
blue
green
54

e.g. Files!
55

better!
BAC947 snake 56

better still
57

What do I notice now?
58

Duplication!
59

What does
assertEquals()
print when it fails?
60

Do your
diagnostics
diagnose?
62

What
diagnostic
do you want?
63

make it pass
64
refactor
write a test for
new
functionality
write a test for
new functionality
ship it!

make it pass
65
write a test for
new
functionality
write a test for
new functionality
refactor
ship it!

make it pass
66
refactor
write a test for
new
functionality
write a test for
new functionality
ship it!
refactor the
diagnostic!

make it pass
67
refactor
write a test for
new
functionality
write a test for
new functionality
ship it!
refactor the
diagnostic!

How about this?
68

Make it so!
69

71
A
B C
D E F
G
external external

72
A
B C
tA
mockist style
B' C'
D E F
G

mockist style
73
A
B C
D E F
G
tB
D' E'
C'

mockist style
74
A
B C
D E F
G
G'
F'
B'
tC

mockist style
code tests
75

classic style
76
A
B C
tA
D E F
G
D' F'

classic style
code tests
77

the.law.of.demeter
78

which is more
important?
the code or the
tests?
80

both
81

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

code and tests
co-evolve
83

evolution is
always co-evolution
84

87
testing
time

88
debugging
time

debugging = removing
what you don't want
89

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

92
testing
time

93
specification
time

94
specific.........
time

Summary
Burning calories - a metaphor for understandability
Tests should be simple, linear, low complexity
Tests should be specific
Long_specific_test_names_are_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"
Beware overusing Mockist style
Code and tests co-evolve
Test at the end is often debugging
Test at the beginning as specification
95

code with no tests
100
FB75B3

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

lessons from testing

Recommended

Recommended

More Related Content

More from Jon Jagger

More from Jon Jagger (6)

Recently uploaded

Recently uploaded (20)

lessons from testing