Further than 100% code coverage

Why chasing after 100% ?

Previously, in this post — The need of a Quality Gate at TheFork, we discussed about the need of the Quality Gate. The Quality Gate is a mean to enforce code quality. Many companies usually require a minimum of around 80% code coverage. Why not 100%? Well, it’s just a matter of cost. It would mean that developers must spend more time writing tests than writing production code.

Despite a good code coverage (even close to 100%), could we really detect everything corner case? Of course not, we might have missed many of the. At the contrary, we cannot completely cover the code with 100% code coverage.

In my team, the coverage is around 85%. Developers have done quite a good job on that matter. However, there are many weak points. Some tests are meaningless, but only to have coverage. That is just waste of time. On the other hand, having relevant tests helps my team to be more efficient delivering features faster. For example, with all the automated tests in place on the project, developers can rely on them to deliver, while doing just the minimum in manual testing. That’s why TDD is a approach that got popular in last 2 decades.

The way we write tests depends on the codebase structure. Let’s first have a look a the layered architecture.

Codebase Layered Architecture

For this article, we will discuss the layered architecture applied to the Spring framework, as presented in the schema below.