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.