Test-Driven Development

You hear some people talking about it, you might have a basic idea, but let's take a closer look because, in the end, it's not as difficult as it might seem from the outside!

What Is It?

Test-driven development (short: TDD) is a software development technique.

Instead of writing all your code first and only then writing your tests, you start with tests, then code a little, then test again, and so on.

It is one specific form of the test-first approach and aims at making software development faster, more reliable, and safer to do. And it especially forces developers into a user role.

By writing tests first, you become a user. You are the first one to ...

experience your own APIs and logic. And you realize sooner whether what you built is really usable or well-worth a full refactor, or even a full rebuild.

"The Cycle"

TDD requires you to work in a cycle. That cycle is well-defined and never to be broken. But don't worry, it's not that complicated and after some time you'll have memorized it pretty well.

The cycle consists of five steps that are repeated over and over again until your feature is finished, or your bug is solved and we'll go over each step of the cycle now.

Scenario

Let's assume a very simple scenario. You want to divide two numbers. And that's it. Only a division. Nothing fancy!

Step 1: Write a test

Yep, you start by writing a test. Your first test can be the simplest thing you can come up with. The only important thing is that you implement it.

A potential first test case for your scenario can be seen below.

Step 2: Run all tests

Now you run your test(s). In the first iteration, your test will of course fail because you haven't even implemented anything, yet. But in subsequent iterations, you must check whether you have to implement more, or are already done.

Step 3: Write code

This step depends on the outcome of step 3. If a test failed, you now have to write some code to make that test case pass (while keeping all other existing tests green, as well).

Important: You only write code that's really necessary!

Step 4: Run all tests

You now have to go and see whether all tests still pass. If they do, this step is finished (if it is, go to step 5). If not, you'll have to go back to step 3.

This mini-cycle repeats until all tests pass again.

Step 5: Refactor

Depending on how often you've already iterated, now is the time to clean up your code and refactor it.

Maybe you can extract a function here, make something more readable there. You use this step to improve your code.

Things to consider in this step:

- removing duplication
- renaming function or method names to something more meaningful (without breaking public APIs of course)
- improving maintainability/readability

Repeat

Depending on whether your feature is finished or not, you either repeat the cycle and start at step 1 again, or you're done and can leave the cycle (for now).

The important thing to keep in mind is: You implement some requirements. And those requirements should be fully covered before you leave the cycle.

Good sources are user stories with acceptance criteria, a specification document, your business analysts, or the client.

No matter which source you choose, in the end, you should have implemented, and tested, what the feature is required to provide to a user of your software.

The Benefits

TDD has some pretty great benefits if applied correctly and forcing yourself to write tests first can lead to interesting results.

Remember that one function where you use fetch to call a remote API? That was difficult or impossible to test, wasn't it?

Such things are actually pretty unlikely to happen with TDD. You are simply required to provide a test. There is no way to skip them.

This way, you put more emphasis on the actual testability of your own code. Such a function like the one mentioned above would surely ...

... become a function that takes another function as an argument. You can mock that parameter-function in your tests, and provide an implementation that actually uses 'fetch' at runtime. And this function could then be tested separately on the integration-level.

The Drawbacks

Getting started with TDD is difficult. It's a complete shift from what most developers are used to.

Thinking upfront, creating test cases, and only then implementing code can be difficult. You have to get used to it and also make a shift within your mind.

When you start out with TDD, you'll need more time to do things. At least you think you do, because what you usually not see is the cost later added when things go wrong in production.

They are far away, occur much later, and are thus harder to connect to the initial ...

... development phase.

However, even feeling that things take longer can have an impact on you, so I consider it a drawback of TDD. But only in the beginning, as stated.

Another drawback is that TDD does only really make sense if a full team employs it practically. Only one team member doing TDD does not solve the overall problem and only works partially. This can be a show-stopper because convincing your colleagues is another huge task.

Conclusion

TDD is a huge shift from what most developers learned to do. Tutorials show you how to build stuff but often don't cover tests. Universities teach CS basics, some programming, some testing, but all decoupled from each other (usually), and ...

... depending on where you work, your colleagues are working traditionally, writing code first, and only then testing it.

But the benefits you can gain by practicing TDD are well worth all the ramp-up and struggle you may have with it in the beginning.

It is a very good investment, both in time and money, and pays off pretty quickly. But you have to be persistent. Once you go TDD, you cannot switch back and forth anymore.