02.15.08
Test-Driven Development Demystified
A lot of people have probably heard of test-driven development, and the buzz around it. There’s evangelists and zealots, frameworks (unit tests and mock objects and acceptance tests, oh my!), and a lot of heated discussion.
What I don’t see a lot of is the basic ideas of test-driven development, distilled and put into a form that most programmers can relate to.
A typical pattern that I’ve seen is the creation of separate applications or workspaces to isolate a component while you’re developing it. If you were to do that with a stack, it might look something like this:
static public void main(string[] args)
{
Stack s = new Stack();
s.Push(“foo”);
s.Push(“bar”);
string test = s.Pop();
System.Console.WriteLine(test);
}
In some cases, you’ll write this before you even write the stack class, as a way to define your API in an outside-in way.
After you’ve written your Stack class, and you get the results you want, you’ll probably look at the insides of it to optimize it, or make it designed better.
If you’ve done this, congratulations, you’ve used test-driven development. No, really. Everything else surrounding TDD is nothing but tools to help write and run these types of testbed or sandbox programs. For an experienced developer, it really is much ado about nothing.