Last Tuesday I gave a presentation for the Engineering Excellence / Trustworty Computing day here in Dublin on Test-Driven Development and Micro-Pairing. Shocking, I know. It was a bit weird wearing a portable mic and being filmed, but a good experience still.
I got most of the usual questions at the end:
- How do you justify the extra time spent writing tests?
- What happens when requirements change and you have to go back and update all your old unit tests?
- How can you come up with a clean, elegant design when you are only adding one small piece of functionality at a time?
- After a few weeks of coding in this manner and you end up with a set of tests, how do you explain to your boss that you have no working code?
Wait, what? The last question threw me for a second before I realised that the final part of my demo had stuck in the guy's head. I had pointed out that for a small class with maybe ten real lines of code, there were already ten unit tests and I could have written more.
What I was trying to demonstrate is that you should expect to have more code in your unit tests than in your actual class — double, triple, or even more. If I ever give that speech again, I'll have to clarify that statement. Feedback is good.
The slide deck is available here. And yes, we do run Office 12, but I know not everyone has ugpraded so it's saved as a 'regular' ppt file instead of pptx.