<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.
So after some revelations I figured out the hard way that working test aware made the code design, cleaner, more S.O.L.I.D . Working test aware was in no way TDD, it was writing code that was tested in isolation against unit tests. Not test driven but test aware. I realized that I saved time if coding, compiling, re-factoring and testing manually or even unit-testing was done in separation from the whole system. If only a set of classes was to be verified then it was just silly to do that through a whole black box setup in the lab.
This is of course not any big new revelation to the world but it was a big revelation and discovery for me personally. This was back during my [HiQ years] but I still had ways to go.
Do you know TDD? In that case you might have realized already that I was on a possible path towards, just that, TDD.
If we speed forward to 2012,
which is a few years later. I am by assignment a R&D Project Manager for Control Software : Neurosurgery. It is a great assignment at an impressive company and I learn a lot of management and aid in creating effective software teams and developing state of the art software. Still, at heart and by commute- and -free time coding I felt like I was still very much a coder. During commuting and in my spare time I continued to code on various open source projects, testing out C++11, studying software and preparing for future concurrency lectures. All the extra time coding was done from my perspective as a test aware coder. Then something happened …
At my employer, Prevas, I was trying to boost their internal educational program by reforming it and spreading it to other offices. At this time discussions with my teams and client pushed toward a TDD workshop. At first I called it Test Aware Development since TDD would, in my mind, be too politically charged. TDD was still a nagging curiosity. I had never tried it out and before completely dismissing it I wanted to understand it. Now I had the chance to be inspired by someone who really knew the TDD area. So I pulled some threads, did a great deal of lobbying and within the Prevas Consultant Education Program (so-so translated from Swedish, but originally with the fun twist “Pre(vas)-School). In the end I got my colleague Mikael Tegnelöv to run a TDD workshop which I promptly signed up for.
It was great. I got practical, from the trenches, experience from a TDD maestro. At the workshop all 12 or so of us could juggle and exchange ideas. Many were even more skeptical then I, but just as curious. The focus was not so much Test Driven Development as it was Test Driven Design (Mikael’s own naming). In the end I was convinced. I was also convinced to call the coming event TDD Workshop instead of Test Aware Development Workshop.
The client’s workshop was thus in the end named TDD Workshop. The workshop lead to many interesting questions and objections that I could not answer. After all I was by experience test aware and not test driven. So I looked to the best, the Sensei Uncle Bob and paid and downloaded his 1st Clean Coders TDD Episode. So there I was, on the train between Uppsala and Stockholm and watching and taking notes on his code-cast. You should know that I am horribly bad at waching code-casts. I find too many issues, aspects and corners that my mind start to investigate. It helps me to keep my sanity if I use a Google doc as napkin replacement to jutting down ideas and code-casts times when something especially upsetting or interesting comes up. This is kind of normal for me, but still after not even watching the whole episode I gave in. I could not take it any longer. Seriously. Two thirds down the code-cast I gave up and shut-down the VLC player. This was rediculous but had to be done. I had not enough patience, Uncle Bob! Resistance was futile. It was impossible to continue to watch any more. I could not help it but was burning to try it out.
Now two days after I downloaded and watched the magical two thirds of Uncle Bob’s code-cast I am almost converted. I have decided to use TDD on all train commute coding and by the end of the summer I hope to be not only practiced in it but also either a firm believer or with a strong belief whether or not the principles of TDD work for me.
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
So far it is fun, more fun then I expected and I already see that the code matures faster with test as the driving point. It is not easy by all means. I easily fall back to code-driven test-aware but I do my best and hope to continue to learn.