Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TDD: The Good Parts

34147b9eecf59779b777eb68a1805113?s=47 Adam Wathan
November 07, 2014

TDD: The Good Parts

Test-driven development can be hard, and a lot of the “rules” can often become a distraction from the real reasons you're writing tests in the first place.

In this talk, you’ll find out what the real benefits of TDD are, what really makes code “good”, and why testability shouldn’t be your only yardstick for measuring code quality.

I’ll also show you some of the pitfalls of a “purist” testing approach, and give you strategies you can use to test-first without sacrificing simplicity or expressiveness in your code.

If you’ve ever given up on testing because it seemed so hard to do everything “by the book”, this talk will feel like a breath of fresh air and give you the tools you need to start writing tests that really matter.

34147b9eecf59779b777eb68a1805113?s=128

Adam Wathan

November 07, 2014
Tweet

More Decks by Adam Wathan

Other Decks in Programming

Transcript

  1. TDD The Good Parts @adamwathan

  2. None
  3. None
  4. None
  5. None
  6. None
  7. None
  8. Code that's hard to test in isolation is poorly designed

    1 Test Driven Evangelists
  9. Isolated testing has given birth to some truly horrendous monstrosities

    of architecture. 1 David Heinemeier Hansson
  10. A dense jungle of service objects, command patterns, and worse.

    1 David Heinemeier Hansson
  11. What makes good code?

  12. 1. Easy to change

  13. 2. Easy to understand

  14. None
  15. 3. Enjoyable to use

  16. None
  17. None
  18. None
  19. What am I doing wrong?!

  20. Why test first?

  21. 1. Confident refactoring

  22. 2. Emphasize public API

  23. 3. Identify task at hand

  24. Isolation is overrated

  25. Pitfall #1 Lying tests

  26. None
  27. None
  28. None
  29. None
  30. None
  31. None
  32. None
  33. None
  34. None
  35. None
  36. None
  37. None
  38. None
  39. None
  40. None
  41. None
  42. None
  43. None
  44. None
  45. None
  46. None
  47. None
  48. None
  49. None
  50. None
  51. None
  52. None
  53. None
  54. Solution #1 Use real collaborators

  55. None
  56. None
  57. None
  58. None
  59. None
  60. None
  61. None
  62. When your tests use the same collaborators as your application,

    they always break when they should. 1 Sandi Metz
  63. The value of this cannot be underestimated. 1 Sandi Metz

  64. Pitfall #2 Implementation coupling

  65. None
  66. None
  67. None
  68. None
  69. None
  70. None
  71. None
  72. None
  73. None
  74. None
  75. None
  76. None
  77. None
  78. None
  79. None
  80. Solution #2 ... Use real collaborators!

  81. None
  82. None
  83. None
  84. None
  85. None
  86. None
  87. None
  88. None
  89. The great irony of over- isolation is that it actually

    makes you more dependent on implementation. 1 Steve Fenton
  90. Pitfall #3 The Dreaded "Design Damage"

  91. None
  92. Easy to understand?

  93. Enjoyable to use?

  94. Easy to unit test?

  95. None
  96. This tests nothing.

  97. None
  98. None
  99. None
  100. None
  101. None
  102. None
  103. None
  104. None
  105. None
  106. None
  107. None
  108. None
  109. None
  110. None
  111. None
  112. None
  113. None
  114. None
  115. None
  116. None
  117. None
  118. None
  119. None
  120. None
  121. None
  122. None
  123. None
  124. None
  125. None
  126. None
  127. None
  128. None
  129. None
  130. None
  131. None
  132. None
  133. None
  134. None
  135. None
  136. None
  137. Solution #3 FOR THE LOVE OF GOD USE REAL COLLABORATORS!!!!

  138. None
  139. None
  140. None
  141. None
  142. None
  143. None
  144. None
  145. None
  146. If talking to the database is stable and fast then

    there's no reason not to do it in your unit tests. 1 Martin Fowler
  147. Testing is an art

  148. ...and a Journey

  149. Push yourself to learn