I Tried Test-Driven Development for A Month and Survived

When I first heard about Test-Driven Development (TDD) I immediately wrote it off as a technique that would 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 realized TDD doesn’t mean what I thought it meant. 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.

You may also enjoy: 4 Tips for Adopting Test-Driven Development (TDD) 

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 TDD 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.

Advantages of TDD

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 was time when writing the unit tests were 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 Toolset

It’s been a while since I wrote Java 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 number 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 higher 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:

xxxxxxxxxx

import hello

import unittest

class TestHello(unittest.TestCase):

    def test_hello(self):

        result = hello.hello_world()

        self.assertEqual(result, 'Hello world!')

if __name__ == '__main__':

    unittest.main()

def hello_world():

    return "Hello world!"

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.

Further Reading

Why Developers Don't Use TDD