When I first heard about Test Driven Development (TDD) I immediately wrote it off as a technique that will slow me down, how on earth should I know exactly what my code will look like if I often refactor while coding. Besides, I’ve been coding for many years and understand how to write code that is “easily” testable. For me it made perfect sense to ignore this crazy idea. Then I realised TDD doesn’t mean what I thought it meant, you see the first time TDD was explained to me many years ago I was told “You write all your unit tests first” and that is what stuck with me. Even now when I ask developers what they understand about TDD that is the response I receive.
So what is TDD?
Test Driven Development is an iterative programming workflow whereby you write a single unit test and then write the code, if required, to make the test pass. When the test passes you refactor your code, including the tests, before writing the next test.
There are more complete definitions available, but I have found that this is a sufficient definition to start a conversation when developers first encounter the principle.
How to practice TDD
What convinced me to try TDD was reading The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin (Uncle Bob). The book dedicates a chapter to TDD and another chapter on Practicing where there is mention of a Bowling Game Code Kata that Uncle Bob uses for demonstrations of TDD. Finding this demonstration online and following it was the introduction to TDD I have been missing. Try it for yourself and then try to apply the workflow to a small problem of your own with a known solution.
http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
Advantages
This is what I found during a month of practicing TDD in different contexts.
It’s strangely natural
Since I started the practice of writing unit tests earlier in my career, whenever I found a bug that did not have a test I would create a new test to reproduce the bug first and only then change the program code until I had a green build again. Turns out I have been doing TDD for bugs all along.
It can be engaging
There are time when writing the unit tests are a lot more interesting than writing the feature code. TDD offers a unique way to make your journey through less interesting code more rewarding.
It’s a good way to pick up an old tool set
It’s been a while since I wrote Java and when I started again the first thing I did was a code kata to try TDD. It forced me to immediately consider the tools needed for testing, rather than get stuck at the end. The amount of times I have told a manager that everything is going according to schedule only to be derailed by unit test tools at the end of a long day when the pressure was on to deliver is probably a lot more than I’d care to admit.
It’s a great way to learn a new language
“Hello world” is the staple of starting a new programming language, but perhaps it does not add enough value for developers who have been coding for many years. Consider this Python program.
print(“Hello world!”)Perhaps we could learn more about a new programming language if our first application was
It improves design
Every time a developer says they don’t know how to test a piece of functionality I assume it is a design problem and often it is. Even with my own code I’ve had to refactor many times when I started writing tests, because some paths were difficult to test. TDD addresses this by making refactoring part of your development cycle.
It improves estimates
The number of teams I still encounter who do not write unit tests and rely completely on manual tests is weirdly high. When these teams start writing tests I find that their estimates can be overly optimistic. Forcing you to think about the tests you will be writing during feature development rather than it being “something you do at the end” helps you mentally keep the whole process in your head.
It’s excellent for pair programming
With ping pong pair programming two developers work together at the same PC. Developer A writes a failing unit test and then Developer B writes the code to make the test pass. Developer B will then write the next failing unit test and Developer A will write the code to make the test pass. It’s a fun way to challenge each other during pair programming and an excellent tool for teaching when a senior and junior developer pairs.
When the feature is complete, so are your unit tests
This goes without saying, but it feels so satisfying when your tests are completed when you have finished your last bit of feature code. Maybe a bug will be found later, but you will always write the test before proceeding to write more feature code.
Final thoughts
With information being freely available we are in a unique position to learn from people without ever having met them. In my case Uncle Bob helped me understand TDD and try it in a safe, zero consequence environment, and it turned out I enjoy TDD.
We should always be trying new ideas and decide if we want it to be part of our workflow. The important thing is to try it for long enough to form an unbiased opinion.
