Why I like Test Driven Development

Jan 23, 2018 · 2 min read

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.

Want to work with us?


Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store