Test Driven Development – I finally get it

Okay, so I did know what TDD was. I’ve read about it. I’ve (sort-of) tried it out. But this morning I was listening to a Hanselminute podcast about TDD and I finally got what it really is. It is NOT “Test” Driven Development. The tests are there only because we happen to use a unit testing tool to help us apply this method of software development.

It really should be called something like “Harness” Driven Development or “Wrapper” Driven Development because what we are doing is creating a software exercising harness to help us design and develop our applications.

The side-effect of having a bunch of unit-tests so we can have confidence in the correctness of our code and so we can quickly test later changes, is great, but it is a side-effect and not the purpose of TDD.

Example: I need view models for the customer related views in an ASP.NET MVC app. So, to figure out the design of how I’m going to do this, I create a class in my “test” project with a method containing the functionality to get one of these view models: I have it instantiate an object of the class that will have this responsibility and make a call to a method on the class that will return one of the view models I need. This is the first step of figuring out the class and the api it will have. Now I can continue with the other steps of TDD. What I am doing here is NOT testing. It is designing and developing in an interactive manner.  It gives me a quick turnaround because I don’t have to fire up the entire application to see if what I just did works, I can run just that single “test”.

It’s not practical to rename TDD to something else because the term is so ubiquitous, but from now on I’m going to name my “test” project “DevWrappers” or “DesignWrappers” or something similar to help me keep in mind that I’m NOT testing, I’m developing.

And now I understand that the “Test” in TDD is a misnomer, I think I will be using it a lot more.