<Part II of my personal reflection series, that started back in February>
A while ago I set out to decide whether or not TDD is my cup of tea. Or rather, it is a cup I have just sniffed the aroma of and have yet to fully taste its flavor, would it be a Lapsang souchong experience or Oolong enjoyment?
I come from a background of safety critical, mission critical and tradition of heavily tested software development. Somehow this made me think that software quality was as natural as breathing air to me. My first years of coding followed the cycle of write, compile, test manually, refactor, code, compile, test manually, test of unit-ish suites when nearing completion, and so on.
TDD was an obscure, XP-derived sect that was fun to read about but quickly set aside in a dark corner in my mind. Placed together with other “this should be fun to experiment with in a distant future”. XP was summarily dismissed as I thought how much so called pair programming had set me back during my university years.
Now. Don’t get me wrong. I have grown into, and still am, a firm believer that code should first be exercised against unit tests before set in place and run with the whole system. This experience came partly from failures of my own and mostly through failures of others that had me cleaning up their disgrace. It was time consuming, annoying and I just kept wondering what possibly could have made this coder to not test her/his code? …Well hands-on, black-box testing in the lab is far from testing all the ins-and-outs of every class,. and just maybe my practice of the art was not that much different from those that failed? There were important lessons to be learned and they had a great impact on me.
Continue reading →