Jan 02 2007
Having read a whole bunch of articles and tutorials about Test Driven Development (TDD) I have finally taken the plunge and started a new project using TDD techniques.
The basic idea of TDD is to write unit tests for your code before you actually start writing any of the function code. The reason for this is to allow you to define how you want to use your functional code (the interface) before you force yourself down a path you didn’t intend to take. It also ensures you tests have better code coverage than if the unit tests are an after thought. But I’ll leave that for another post.
For now I want to focus on an article I read over on Code Project: Test-Driven Development in .NET. In particular I want to focus a sentence in the introduction of the article:
Test-driven development (TDD) attempts to resolve this problem and produce higher quality, well-tested code by putting the cart before the horse and writing the tests before we write the code.
What really struck me about this post was the idea of putting the cart in front of the horse and how this relates to software development.
If we take this quote literally we can extract the following definitions:
- The horse is the end deliverable product.
- The cart is the process required to deliver the end product.
This may seem a little contradictory to normal practice. Why would you use a cart to deliver a horse? If, however, we change the definitions around and say that the cart is what we are trying to deliver and the horse is how we ensure the product gets to the destination in working order and on time it is easier to see how the analogy fits, and it should read something like:
Previously developers had been dragging the horse along behind the cart, in a process that is not only hard work but is also a waste of resources. TDD turns this around and uses the horse to pull the cart ensuring the cart gets there efficiently.