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!

So the steps he walked me through was similar to the process described in Baeldung’s blog post. Other subject, but same minimal steps: write test, fail, fix code. Repeat. And you know, I get that. I understand what the TDD process wants to do. And in some way I even agree with it, but the experience was a big exercise in frustration! It felt like micromanagement to the max. As if all knowledge was taken away from me, and all I was allowed to do was tick of a checklist over and over again, like some dumb robot. Totally ignoring the experience I accumulated by hammering away at computer keyboards for the last 30+ years.

If someone would ask me to write a list in Java, based on my experience, I immediately have a good idea of where the implementation should be going; the index, the array, quick memory copy. I can envision that immediately, and having to go through those small cycles was frustrating: I know where I am going, can I please be productive???

Ok, some may say, this is just a example, a test case. Of course you know how a list will code out, but when venturing into the unknown TDD is great! And yes, you are right about that example. But when I do not have a clear idea of what I have to write, the TDD process severely limits my play doh. Writing to code me is somewhat like sculpting; I have a general idea where I want to go, but as I chug along new insights come and I improve the code. Having so many tests that early in the process, creates a drag and will stop me from refactoring.

So that one experience was enough for me. Automated tests are great and I’m still a big advocate of them, but as regression tests after the code is written.

That said; TDD only applies to new code. Bugs are fixed by first writing a (failing) test, and then fix the bug. The test then serves as a regression test. Oh, and Behavior Driven Development (BDD), where you have a functional specification (user story) and use for example Cucumber to actually automatically test that, is something different. Because that is what you are trying to do with writing your code; make a user story work.

But TDD? No thank you. Have fun.