Download to read offline
Uploaded byJon Jagger
Lessons from Testing
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.
Lessons from Testing
- 1. Lessons from Testing examples taken from http://cyber-dojo.org @JonJagger jon@jaggersoft.com 1
- 2. Avoid unnecessary burningof calories! 2
- 3.
- 4. what do Inotice? E09E8C snake 4
- 5.
- 6. Suppose we measure the average cyclomatic complexity of the code under test and the test code. 6
- 7. Higher number meansmore complex. 7
- 8. tests code 3.7> 2.1 8
- 9. tests code 3.72.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 Inotice most? 18
- 19.
- 20. Duplication usually indicates a missing abstraction 20
- 21. what do Inotice now? 21
- 22.
- 23.
- 24. what do Inotice now? 24
- 25.
- 26.
- 27. what do Inotice now? 27
- 28.
- 29.
- 30. what do Inotice now? 30
- 31.
- 32.
- 33. what do Inotice now? 33
- 34.
- 35.
- 36. what do Inotice now? 36
- 37.
- 38.
- 39.
- 40.
- 41. 41 1.0 Specific? 21F1F3 alligator
- 42.
- 43.
- 44.
- 45.
- 46. Repetition can indicatea missing abstraction 46
- 47.
- 48.
- 49.
- 50.
- 51.
- 52. what do Inotice? DE3BF3 buffalo 52
- 53.
- 54. What's left? redWTF? blue 54
- 55.
- 56.
- 57.
- 58. What do Inotice now? 58
- 59.
- 60. What does assertEquals() print when it fails? 60
- 61.
- 62. Do your diagnostics diagnose? 62
- 63. What diagnostic doyou want? 63
- 64.
- 65. Make it so! 65
- 66.
- 67. 67 A BC D E F G external external
- 68. 68 A BC 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 codetests 71
- 72. classic style 72 A B C tA D E F G D' F'
- 73. classic style codetests 73
- 74.
- 75.
- 76. which is more important? the code or the tests? 76
- 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.
- 82.
- 83.
- 84.
- 85. debugging = removing what you don't want 85
- 86. if you getrid of what you don't want, will you be left with what you do want? 86
- 87. if you getrid of what you ? don't want, will you be left with what you do want? 87
- 88.
- 89.
- 90.
- 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.
- 93.
- 94.
- 95.
- 96. code with notests 96 FB75B3
- 97.
- 98. Lesson ONE testcode must be much simpler than the code it tests 98