Why it is faster to write unit tests?

"We don't have the time to write unit tests", "we write the unit tests because it is mentioned in the definition of done", "we write the unit tests at the end of the sprint"... How many times did you hear or maybe say that?

The purpose of this thread is to prove that writing unit tests, particularly before testing in runtime, can help you to be more productive and efficient. To begin, let's compare the development process with and without unit tests.

Without unit tests

How a developer works without unit tests?

1. Development phase
• Write the entire code of the feature
2. Runtime test phase
1. Constat a bug
2. Analyse where the bug comes from
3. Fix the bug
4. Test if the correction is correct
5. Continue the test phase until all tests are correct

With unit tests

Now, how a developer works with unit tests?

1. Development phase
1. Write a unit test
2. Write the corresponding code
3. Write another unit test until the feature is completely developed
2. Runtime test phase
1. Constat a bug
2. Analyse where the bug comes from
3. Write a unit test reproducing the bug
4. Fix the bug
5. Test if the correction is correct
6. Continue the test phase until all tests are correct

Runtime test phase is expensive

The runtime test phase (with or without unit tests) takes a lot of time for several reasons :

• For each test, you have to prepare a set of data, even for the margin cases
• You have to launch your application
• You have to play your test and maybe find a bug
• For each bug, you have to find where to fix the bug, possibly using a debugger
• Then, you have to fix your code
• Finally, you test again to be sure that your fix is correct. For that, of course, you have to prepare a new set of data

Runtime test phase is longer without unit tests

With unit tests, you can be sure to find most of the bugs directly during the development phase. Of course there are still some bugs but less than if you write no unit tests at all.

So if you have more bugs without unit tests, the runtime test will be longer.

Now, how can be sure without unit tests that a bug fix hasn't broke a functional case you have already test? Are you sure all your code is still working? Maybe you should restart the runtime test phase from the beginning? And what about refactoring your code?

With unit tests, you can be very confident to haven't broke anything because all the tests you have already written can prove you that. Plus, you won't be afraid to do refactoring in order to have a cleaner and more comprehensible code, what will help you to work more efficiently during the next developments.

Conclusion

Of course it is faster to write a code without doing units tests. But how much extra time do you spend testing in runtime or fixing bugs in production?

Less bugs also mean less stress and more time to work on interesting things.

In bonus, you do more code and less functional tests. That's cool, coding is what you are good for!

What about integration tests?

An answer to resolve the cost of the manual tests are the integration tests. Do you still need to do unit tests with integration tests? It is enough to do only unit tests? It is a very interesting question I will try to answer in another thread. But yes, unit tests and integration tests are complementary.