Test-First Programming (TDD)

In reading Extreme Programming Explained, by Kent Beck, I found the section in Chapter 7 on Test-First programming very interesting.  We’ve been working towards this for awhile at work, and I think maybe these four points really drive home the importance:

  • Scope creep – It’s easy to get carried away programming and put in code “just in case.” By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding. If you really want to put that other code in, write another test after you’ve made this one work.
  • Coupling and cohesion – If it’s hard to write a test, it’s a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test.
  • Trust – It’s hard to trust the author of code that doesn’t work.  By writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you.
  • Rhythm – It’s easy to getlost for hours when you are coding. When programming test-first, it’s clearer what to do next: either write another test or make the borken test work. Soon this develops into a natural and efficient rhythm – test, code, refactor, test, code refactor.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>