I was commenting on Test Driven Development in one of the Ruby groups on LinkedIn today, and realized it might make a decent blog post. So here we go:
The "purpose" of TDD is somewhat controversial, and also depends just how you do it. The traditional approach is "think of what you want it to do, think how you would test that, write the test, verify that the test fails (because you haven't written the code to make it pass), then write JUST enough code to make the test pass, preferably the simplest thing that could possibly work". Those who care strongly about clean code (most who use TDD do anyway) would then add "clean up your code, and your test, to get rid of any 'smells'" (which is one of our terms for things that aren't necessarily wrong, but at least indicate that there might be something worrisome going on).
BUT....
Nowadays a lot of people are actually using TDD to mean Test Driven Design, not just Development. Rather than having an overall design in mind and approaching each feature with the bias towards that design, just really do the Simplest Possible Thing, and let that influence your design. (In more ways than just making it more modular and testable, as it always has.) Some would say that since it applies to both design (the overall pattern, perhaps a level below architecture) and development, it should be TDDD, or as our defense contractors would probably then call it, T3D. ;-)
