lessons from testing

Lessons from Testing

1

examples takenfrom

http://cyber-dojo.org@JonJagger

[email protected]

Thursday, 23 October 14

2

Avoid unnecessary burning of calories!


FizzBuzz

3


E09E8C snake 4

what do I notice?


5


6

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

code.


7

Higher number means more complex.


codetests

8

3.7 2.1>


codetests

9

3.7 2.1

teststests

4.3 >>


codetests

10

3.7 2.1

teststests

4.3NO!>>


codetests

11

2.1 2.1==


codetests

12

2.1 2.1==NO!Thursday, 23 October 14

codetests

13

2.0 2.1<


codetests

14

2.0 2.1<NO!Thursday, 23 October 14

codetests

1.0 2.1

15

<<<


codetests

1.0 2.1

16

YES<<<


17E09E8C wolf

~> Simple1.0


18

what do I notice most?


19

Duplication!


20

Duplication usually indicates

a missing abstraction


21

what do I notice now?


22

Duplication!


23


24



25

Duplication!


26


27



28

missing examples?


29


30



31

better test names?


32


33



34

different_identifier_style?differentIdentifierStyle?


35

that's ok!


36



37

duplication?


38

this is worse!


39

how about this?


40


41

1.0

Specific ?

21F1F3 alligator


42

!Thursday, 23 October 14

43

Specific ?


44

Specific :-)


45

Repetition ?

?


46

Repetition can indicate a missing

abstraction


47

Specific


48

Specific


49


50

Recently Used List


51

e.g. Recent Files...


52DE3BF3 buffalo

what do I notice?


53

Duplication!


54

What's left?

WTF?redbluegreen


55

e.g. Files!


56BAC947 snake

better!


57

better still


58

What do I notice now?


59

Duplication!


60

What does assertEquals()

print when it fails?


61


62

Do yourdiagnostics diagnose?


63

What diagnostic

do you want?


64

refactor

write a test fornew

functionalitywrite a test fornew functionality

make it pass

ship it!


65

write a test fornew


make it pass

ship it!

refactor


66

refactor

write a test fornew


make it pass

ship it!

refactor the diagnostic!


67

refactor

write a test fornew


make it pass

ship it!

refactor the diagnostic!


68

How about this?


69

Make it so!


70


71

A

B C

D E F

G

external external


72

A

B C

tAmockist style

B' C'

D E F

G


73

A

B C

D E F

G

mockist style

tB

E'D'

C'


74

A

B C

D E F

G

mockist styleG'

F'

B'

tC


75

code tests

mockist style


76

A

B C

tA

D E F

G

classic style

D' F'


77

classic style

code tests


78

the.law.of.demeter


79


80

which is more important?

the code or the tests?


81

both


82

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


83

code and testsco-evolve


84

evolution is always co-evolution


85


86


87

testing

time


88

debugging

timeThursday, 23 October 14

89

debugging = removing what you don't want


90

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


91

?Thursday, 23 October 14

92

testing

time


93

specification

time


94

specific.........

time


95

SummaryBurning calories - a metaphor for understandabilityTests should be simple, linear, low complexityTests should be specificLong_specific_test_names_are_ok Duplication usually means a missing abstractionRepetition can indicate a missing abstraction tooDo your diagnostics diagnose? Custom assertionsDon't cheat on test data - "String1" vs "red"Beware overusing Mockist styleCode and tests co-evolveTest at the end is often debuggingTest at the beginning as specification


96


97


98


99


100

code with no testsFB75B3


101


102

Lesson ONE

test code must be much simpler than the code it

tests


lessons from testing

Software

tests code2

tests code3

tests code4

codeunder test

higher numbermeans morecomplex

testingexamples takenfromhttp

unnecessaryburning of

e09e8c snake