Code Coverage Testing in Java: From JUnit to JaCoCo in Practice

Code Coverage Testing in Java: Tools and Metrics in Practice

Have you ever felt like a ship captain who is confident his vessel is unsinkable, but has never checked the hull for leaks? Developing in Java without analyzing code coverage looks roughly the same. You write tests, but you don't know how well they actually protect your project from bugs. In this article, we will break down what code coverage testing in Java is, which code coverage tools truly help you avoid drowning in regressions, and how to correctly read metrics so you don't deceive yourself.

Why Simply "Writing Tests" Is Not Enough?

Many developers think: "I wrote 50 tests — so the project is protected." But the number of tests does not equal quality. Without metrics, you risk:

\n
• Missing entire branches of logic (for example, exception handling);
\n
• Testing only "happy paths," ignoring edge cases;
\n
• Wasting time on tests that don't verify new code.
\n

This is precisely where Java code coverage comes to the rescue — an objective assessment of what percentage of the source code is executed during tests. It's not a panacea, but a powerful compass for the team.

Key Code Coverage Metrics in Java

Before choosing a tool, let's understand what exactly we are measuring. In the Java world, four key metrics stand out:

1. Line Coverage

The simplest metric: how many lines of code were executed at least once. If a line is not executed, it means no one tested it. Example:

public int divide(int a, int b) {\n    if (b == 0) {\n        throw new IllegalArgumentException("Division by zero"); // Line 3\n    }\n    return a / b; // Line 5\n}

If your test calls divide(10, 2), then line 3 will remain uncovered. Java line coverage will show 50%.

2. Branch Coverage

This metric is trickier. It checks whether all logical paths (if-else, switch, ternary operators) have been traversed. For the same divide method:

\n
• Branch 1: b == 0 (true) — exception thrown;
\n
• Branch 2: b != 0 (false) — division.
\n

If you only tested division, branch coverage will be 50%. If you add a test with b=0, it becomes 100%.

3. Condition Coverage

A deeper metric that looks at each sub-condition in complex expressions. For example, in the code if (a > 0 && b < 10), you need to check 4 combinations: (true, true), (true, false), (false, true), (false, false).

4. Mutation Coverage

The gold standard. A tool (e.g., PIT) makes small changes to the code — changes >= to <, removes a method call — and checks if at least one test fails. If a test doesn't fail, it means it is not sensitive enough. Java mutation testing is the best way to assess test quality, but it is slower.

Top Code Coverage Tools for Java

The market offers several mature solutions. Let's look at the most popular ones.

JaCoCo — Industry Standard

JaCoCo (Java Code Coverage) is an open-source library that integrates into the build (Maven, Gradle) and generates reports in HTML, XML, or CSV. It supports all major metrics except mutations.

Example configuration in Maven (pom.xml):

<plugin>\n    <groupId>org.jacoco</groupId>\n    <artifactId>jacoco-maven-plugin</artifactId>\n    <version>0.8.11</version>\n    <executions>\n        <execution>\n            <goals>\n                <goal>prepare-agent</goal>\n            </goals>\n        </execution>\n        <execution>\n