Add to Google
The Simple Math Behind TDD?
Posted on November 25, 2008 by Dean Leffingwell in Team PracticesFor those who have followed this blog or read the book, you might know that I called Chapter 13 of SSA “Concurrent Testing” and not TDD (Test-Driven Development). I talked about TDD in the book, but I didn’t specifically prescribe it. TDD says:
- Write the test
- Run it and watch it fail (meaning build it permanently into the test harness and execute it there)
- Write the minimum amount of code necessary to pass the test
- When it passes the test, go work on another story!
At the time I wrote the book, TDD was still a little edgy and had not crossed the chasm to the mainstream, even the early agile mainstream. It it just hard for some developers to get their head around this early investment in test case development as it changes the way they think about coding (though for the better). And I suspect that is still likely the case. So I was generally happy with the Concurrent Testing chapter, because it drives teams to be able to “unit test-acceptance test-component/feature test-system test”, all in the course of an iteration. Good enough for me.
However, last week I was with a client along with Amir Kolsky of Net Objectives. Amir is a TDD expert and proponent and he advised the client to always “write the test first”. We had a minor debate about the differences in viewpoint. After all, if the team leaves the short, two-week iteration with everything tested, isn’t that about as good as it gets?
Well, actually not. Amir led us through this “simple TDD math exercise”.
First:
Next:
and finally:
I had to admit that I had seen plenty of rework time (Rt)in recent iterations so it was fairly easy for me to support this simple conclusion.
After our meeting, I attended iteration demos from a number of teams and I saw quite a bit of Rt there too.
Ok, write the test first!
Sometimes a math proof is all an engineer needs to make it viable.
Nice write up!
Dean:
I like this. However, Amir left out half the equation (which makes it even better for TDD).
This is good, but not quite complete.
The other factor is:
S = savings by having the conversation before starting any work.
Makes it Story (if write tests first) = T + C + H – S
Or Story (if write tests later)= T+C+H+R+S
Notice this comes into play even if you just have the conversations about the tests – that is specify them up front. It is often easier to get people to transition to TDD by pointing this out, because it is clear that defining them up front takes no extra time at all. But once they are defined, that is the perfect time to write them.
I’ve been championing a TDD grassroots movement at Inovis, and it is good to see analytical arguments about the benefits over parallel testing (which describes what most developers in our company do today).
Additionally, the time to hook the test Ht is often significantly reduced in a test-first approach. Objects designed without testing in mind often require redesign (which ripples to collaborating objects depending on how much development has been done prior to testing) in order to properly expose testing hooks that provide access to values necessary for test assertions & collaborators that need to be mocked out for isolated unit testing.