2025
You've probably heard about TDD, but do you practice it?
TDD stands for Test Driven Development. TDD is a software development approach where an engineer writes automated tests before writing the corresponding code. What is often then lost off descriptions of TDD is that this process involves writing a single test case for new functionality, then writing just enough code to make the test pass, and then refactoring the code and test.
It treats tests as equal in importance to code, a mantra that rather resonates with me. It also avoids any chance of over-engineering problems. Each instance of your development cycle will have clean code, with the full security of tests. Indeed, even if you stop after writing a failing test, another engineer with no knowledge of the code or your workcycle, will be able to quickly identify the current state and your full intent.
It's important to note that Test Driven Development is a discipline. It's an ideal that you aim to practice, but it's not a set-in-stone list of rules, and you can bend them to suit your situation if it makes sense.
Practicing TDD doesn't require any form of process, and it can be completely invisible outside an engineer's personal way of working. This makes it very easy to implement, as you don't need anyone to agree to buy into it. All that will happen is that you will find, and you may find others noticing, that you are writing better code. Code with less errors, and more reliability.
Another misconception is that TDD is just about writing tests. If you write all the tests, cover all the code, you're doing TDD. Sorry, to tell you, but you're not.
If you've ever practiced TDD, or watched anyone practice it, you'll see that it frames things in a very different light. It's much more about keeping your focus on a deconstructed view of the system, focussing on achieving the simplest solution to each objective, while still considering previous ones. You write a test that descrives what you want the system to do, you make it work, you refactor. You should only ever have one failing test. Of course, in practice this doesn't always work like this, but at almost any juncture, the tests that fail are always obvious in why they fail. They are simple, clear, compartmentalised.
While practicng TDD I have never seen, both in my own code and others, more than 2 tests fail as the result of a change. And that includes working in codebases with tests that contain overly-prescriptive Requirements, (seeThe art of writing tests)[/blogs/writing-tests]
You may well have heard many critiques and shortcomings of TDD. And I'm not here to try to claim that they don't exist. They absoliutley do. But most of these complaints focus on the shorcomings as if TDD were to be implemented as a single standalone practice. TDD is a discipline, and one that is not designed to function in isolation. For example, if you have not embraced agile, of course TDD seems rigid.
Possibly the most common argument against TDD is that it takes longer, and due to business priorities, you "don't have time" to write tests. But this criticism ignores the fundametal principle of TDD, and at the same time reduces a software engioneer to a pure code-writing monkey. Trul;y valuable software engineers cannot have their worth measured in lines of code. They typically spend less than 10% of their time actually writing the code. The rest of the time is spent conceptualising, understanding the existing code, and imagining the designs of potential solutions. The act of writing tests in TDD is as much about solidifying the intent of the engineer as it is about being a safety net to catch issues.
On top of this, well-written, well-tested code enables engineers to much more efficiently understand the existing code, and so as a long-term business strategy it makes perfect sense to implement. By not writing tests you are acting short-sightedly, gaining 10% this week at the expense of 5% for every month thereafter.