Why TDD is Faster than Unit Testing

In this article, I'll try to prove that TDD (Test Driven Development) can be faster than just Unit Testing.

For clarity, by TDD I mean writing unit tests before the code. And I will refer to unit tests that are written after the code as just "unit tests" or "regular unit testing".

Note about accuracy of the information: I personally follow TDD on daily basis, and I have followed regular Unit Testing as well in the past, just before I matured into TDD. So, let's agree, I know what I'm talking about.

Side by Side - TDD vs. Unit Testing

I won't go into details about the process behind TDD or Unit Testing, but I will provide visuals representing these processes. This will serve as a vocabulary afterwards.

As you can see, I tried to be consistent when naming steps of both these approaches. This shows there are similarities, and the number of steps is somewhat equal, too. But those steps mean slightly different things for each approach. That's where I want to dig to reveal the truth.

Down to the Weeds

I'll pick each step from TDD and will compare it to the same step from regular unit testing process.

Decide What You Are Going to Write

Let's swallow the frog and say that TDD loses right away with the first step.

While with regular unit testing you don't need to think too much and can jump right to coding, you can't do so with TDD. Thought process is slightly different, and requires more discipline and more skills. You need to do one of the following:

1. Skatch what you are going to touch, and how classes and interfaces are going to collaborate (difficulty level - advanced).
2. Imagine the code you are going to write, but just don't write it (difficulty level - intermediate).
3. Write the code and then comment it out; be ready to throw it away or rewrite after unit test is written (difficulty level - beginner).

Regardless of which trick you use, it will take more time than it took for regular Unit Testing. The more advanced approach you take, the more time it will take to accomplish.

But don't judge too early. The more you practice TDD, the faster you will be handling this step in more advanced ways. Eventually, you'll start loving yourself for being so good at it.

Besides, while you can jump to coding right away with regular unit testing, who said that it's a good idea? It's like acting without thinking, so maybe TDD does not really lose at all...

Write Unit Test

Now, you need to write unit test. It's much easier to write unit test when you don't need to study the code which you are going to cover. There is no code - there is no headache. Just write unit test the way you want it to be. TDD catches up on this step quite rightfully.

With regular unit testing, you not only need to study the code that you need to cover (even though you probably just wrote it), but you also need to fix the code from time to time to make it unit testable. There are always some small things that you cannot think of when you are writing code - while being so excited that you don't want to bother with thinking about unit tests. And one more issue - now the code is written, so you also need to fight the procrastination and be bored to death to write the unit test for already working code.

Write Code to Pass Unit Test

That's straightforward with TDD. You just need to stop your temptation from writing too much, but that's not too difficult, because at this point it has become almost like a game with yourself.

With regular unit testing, you are writing code in about the same way. Except - you probably write more code than you need to (again, developer's excitement, or better - anxiety). Not only did you introduce some potentially dead code (which real use cases never needed), but you also need to cover that with unit tests later on - so yes, you just added overhead to unit testing as well.

So, on this step, TDD wins.

Run Unit Tests to Verify They Pass

Both processes require about the same effort to run unit tests for verification purposes, but regular unit testing should lose a bit here. That's because you will need to keep adjusting unit tests to make them pass finally. Changing the working code is the last thing you want to do at this point. If you do change the working code, then you have to ensure it still works now, so no way.

With TDD, the test is already written, the way it should be. You just expect it to pass now that the code is written.

Run Program to Verify Code

Final step, and the biggest advantage of TDD - running program to verify the code correctness.

With TDD, you probably have to run 1-2 times. And in most cases, it will work fine, because the unit test has already passed as a verification of that exact code.

With regular unit testing, on the other hand, you are doing this exercise while writing code. You can either write too much code and then debug every single step and keep fixing it, or you can write small piece at a time and run it. Either way, running, debugging, and fixing is much slower than just executing unit tests.

So in this step again, TDD takes over.

And the Winner Is...

If you read all this and kept open minded, and if you have not started practicing TDD yet, it's about time now.

Unit testing, TDD, and other Test-First approaches are some of the great ways to increase the development skills and get into the next level of engineering. I can help with this - I provide a training course about Test-First Development practices for groups.

About Author and Content