Why I like Test Driven Development

This article originally appeared on medium at https://medium.com/@defmyfunc/why-i-like-test-driven-development-a8b41c4dec6f

This may be stating the obvious but as a ThoughtWorker, I am obviously a massive proponent of Test Driven Development.

There are probably as many reasons ThoughtWorks espouse this technique as there are ThoughtWorkers and each person has their own reasons and or experience that has lead them to this path (or driven them from it!) and I wanted to write a bit about mine.

The views in this article are my own and are not necessarily endorsed by my employer.

The reason I use this technique a lot is because I believe in the maxim** ‘if you want to understand something, teach it’**.

If find TDD the quickest way to shortcut to this state, without y’know, actually having to teach it in the traditional sense :)

With TDD I have it lay out all up front. All my assumptions and knowledge about what I am going to do are crystallised in front of me. By writing the test first, I have to grapple with making sure I understand what I am trying to achieve, what I do and don’t know about what I am going to do, and what assumptions I am making about how much I need to know about how it all works.

Hopefully I am pairing, so I have to explain and discuss this with my pair first. Often, I’ll go through a few pairs, for instance, I quite like being able to ensure I can explain it in different ways. I generally ensure that a BA, QA and other Devs can all understand what it is I am trying to achieve, meaning that as a team we are forced to align around our goal. Writing the test first, as an expression of value, helps me do this, and have this conversation.

One of the particularly fun things I find around TDD is that sometimes it can feel like the software or system(s) is challenging back. Like it is the first ‘pair’ I have to convince of the approach I am taking. Wrestling from me the assumptions I have made as to how it works. This is especially useful in large teams (whether you build monoliths or groups of microservices or whatever) were you are not the only person commiting code :)

(As a side note I tend towards classicist, value driven, test can be anything from live monitoring to individual function unit level, kind of TDD)

What I think is relatively unique about TDD as a technique, is not that what it achieves in terms of knowledge, alignment, certainty, reliability, confidence, automation etc, etc, can’t be achieved with other techniques. However, as a single technique, I think TDD is relatively unique in bringing all these good things I want to achieve, together.

At the end of the day, TDD is obviously ‘just a tool’ and should be used when appropriate, and understanding when a technique is not appropriate is just as important as when it is appropriate.

Happy TDD-ing (if you want to).

The views in this article are my own and are not necessarily endorsed by my employer.