Kent Beck
A real clear look at what TDD is, and how to go about using it in writing your own software.
Test first, which gives you a ‘red bar,’ or proof somewhere that something doesn’t work. Test one thing at a time – from everything working (green bar), write one test which illustrates the next idea you would like to implement and also fails (because you haven’t implemented the required feature yet). Then do the littlest amount of work you can to make the test pass, and go back and keep writing small tests and passing them.
The tests give you a confidence in your code that you wouldn’t otherwise have, when you mess something up one of your tests will also get messed up and tell you that there is a problem – so have enough tests and run them often. Sort of like in GTD, get everything out of your head, so you can use your head to work on the problem at hand and not try to keep all kinds of other littler things back there.
Tests also let you make large and functional changes to the innards of your application, then verify that nothing is broken. They encourage refactoring, improving your code to be more efficient, simpler, overall better. Refactoring encourages code iterations that would be hard to do without the whole backbone of tests already written to ensure that you were still on the right track.
Tests also help you stay on track – once you have a red bar there is just one thing to accomplish: bring back your application to green bar status, where no tests fail. Just like GTD, keep everything not essential to the task immediately at hand somewhere out of mind, a to-do list. Once your back at the green bar and satisfied with your code, pick the next thing to implement off your list, and go at it until you’ve written and passed an exacting test of what you had originally wanted to program.
Tests are the Programmer’s Stone, transmuting fear into boredom. “No, I didn’t break anything. The tests are all still green.” The more stress I feel, the more I run the tests. Running the tests immediately gives me a good feeling and reduces the number of errors I make, which further reduces the stress I feel. 124
Test first, and it’s kind of like defining the goal you want to accomplish before going off and working on accomplishing it. Like picking a major in college and doing everything you can to get that major before drifting between classes and getting all kinds of worthless credits and ending up with a major in physical therapy. Make sure you spend your time working on what you should be working on.
Make the tests pass, then use more test and introduce complexity into your tests to provide for coding abstraction. You can always have a function that just returns the exact value your test is looking for – but when you add a second test looking for something else (triangulation?), your going to have to change the method. Eventually, you will want to remove all duplication between application and test code, which will require the application be abstracted. By now you should already have adequate tests in place to ensure the abstraction works!
TDD looks like the right way to start out programming, and going with it early on as I learn should be fun.
