TDD; an exercise in frustration
Recently I read an article about How to TDD a List Implementation in Java and it suddenly reminded me of an experience a colleague made me go through a few years back. At that time the company I was working for had a big piece of software with almost no automated tests, and they (of course) had stability issues. So I was an advocate of starting to write automated tests; by developers, by testers, unit tests, UI tests, the works, in an attempt to get the software stable.
After a year of hard work solely focused on bug fixing and writing tests, it finally started to pay off. (Yes, that is what it takes; the company decided to not release any new features for a whole year, but in the end it paid off big time. Major growth in market share, because clients took notice. But it took guts to choose that path.)
Testing had become common practice by then and at one point a colleague came up to me and asked me what I though about Test Driven Development (TDD). I said that it didn’t feel right, so he asked me if I wanted to give it a try.
Well… Of course!