Coverage reports in JUnit - Test Execution Trace

Test Overview

This test runs a simple JUnit test case and generates a coverage report to verify which parts of the code were executed during the test.

Test Code - JUnit 5

JUnit

import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;

class Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public int subtract(int a, int b) {
        return a - b;
    }
}

class CalculatorTest {
    @Test
    public void testAdd() {
        Calculator calc = new Calculator();
        assertEquals(5, calc.add(2, 3));
    }
}

Execution Trace - 5 Steps

Step	Action	System State	Assertion	Result
1	Test runner starts and loads CalculatorTest class	JUnit test environment initialized	—	PASS
2	JUnit executes testAdd() method	Calculator instance created, add method called with (2,3)	assertEquals(5, calc.add(2, 3)) verifies result is 5	PASS
3	Test completes successfully	Test method finished without exceptions	—	PASS
4	Coverage tool analyzes which methods were executed	Coverage data collected for add() method, subtract() method not executed	Coverage report shows add() method covered, subtract() method not covered	PASS
5	Coverage report generated and saved	Report file available with coverage summary	Report confirms 50% method coverage for Calculator class	PASS

Failure Scenario

Failing Condition: TestAdd method fails assertion or coverage tool fails to generate report

Execution Trace Quiz - 3 Questions

What does the coverage report indicate after running the testAdd() method?

A No methods were covered

B Only the add() method was executed and covered

C Both add() and subtract() methods were covered

D Only subtract() method was covered

Key Result

Generating coverage reports helps identify which parts of the code are tested and which are not, guiding better test coverage and quality.

Practice

1. What is the main purpose of a coverage report in JUnit testing?

easy

A. To show which parts of the code were executed during tests

B. To list all test cases in the project

C. To measure the speed of test execution

D. To generate test data automatically

Solution

1. Step 1: Understand coverage report purpose

   A coverage report shows which lines or branches of code were run during testing.

2. Step 2: Compare options to definition

   Only To show which parts of the code were executed during tests matches this purpose; others describe unrelated features.

3. Final Answer:

   To show which parts of the code were executed during tests -> Option A

4. Quick Check:

   Coverage report = executed code lines [OK]

Hint: Coverage reports highlight tested code lines quickly [OK]

Common Mistakes:

• Confusing coverage with test case listing
• Thinking coverage measures test speed
• Assuming coverage generates test data

2. Which tool is commonly used with JUnit to generate coverage reports?

easy

A. JaCoCo

B. JUnitParams

C. Mockito

D. Selenium

Solution

1. Step 1: Identify coverage tools for JUnit

   JaCoCo is a popular Java code coverage tool that integrates with JUnit.

2. Step 2: Eliminate unrelated tools

   Selenium is for UI testing, Mockito for mocking, JUnitParams for parameterized tests, not coverage.

3. Final Answer:

   JaCoCo -> Option A

4. Quick Check:

   Coverage tool with JUnit = JaCoCo [OK]

Hint: JaCoCo is the go-to coverage tool for Java tests [OK]

Common Mistakes:

• Confusing Selenium with coverage tools
• Mixing mocking frameworks with coverage
• Assuming JUnitParams generates coverage

3. Given this JaCoCo coverage summary:
Lines covered: 80
Lines missed: 20
What is the coverage percentage?

medium

A. 100%

B. 20%

C. 80%

D. 60%

Solution

1. Step 1: Calculate total lines

   Total lines = covered + missed = 80 + 20 = 100 lines.

2. Step 2: Calculate coverage percentage

   Coverage % = (covered / total) * 100 = (80 / 100) * 100 = 80%.

3. Final Answer:

   80% -> Option C

4. Quick Check:

   80 covered of 100 total = 80% [OK]

Hint: Coverage % = covered lines ÷ total lines x 100 [OK]

Common Mistakes:

• Using missed lines as coverage
• Forgetting to add covered and missed for total
• Mixing up numerator and denominator

4. You ran tests with JaCoCo but the coverage report shows 0% coverage. What is the most likely cause?

medium

A. Tests did not execute any code

B. JaCoCo was not properly attached to the test run

C. All tests passed successfully

D. The source code is empty

Solution

1. Step 1: Analyze 0% coverage meaning

   0% coverage means no code was recorded as executed during tests.

2. Step 2: Identify common causes

   If tests ran but coverage is zero, JaCoCo likely was not attached or configured correctly.

3. Final Answer:

   JaCoCo was not properly attached to the test run -> Option B

4. Quick Check:

   0% coverage usually means missing JaCoCo setup [OK]

Hint: Check JaCoCo setup if coverage is zero [OK]

Common Mistakes:

• Assuming tests passed means coverage is full
• Thinking empty source code is common
• Ignoring JaCoCo configuration errors

5. You want to improve your test coverage report by including branch coverage in JaCoCo. Which configuration change is needed?

hard

A. Increase the number of test classes

B. Add @BranchCoverage annotation to test methods

C. Use a different testing framework instead of JUnit

D. Enable branchCoverage option in JaCoCo plugin settings

Solution

1. Step 1: Understand branch coverage

   Branch coverage measures if all decision branches (like if/else) are tested.

2. Step 2: Configure JaCoCo for branch coverage

   JaCoCo supports branch coverage via plugin settings; enabling branchCoverage activates it.

3. Step 3: Eliminate incorrect options

   No annotation @BranchCoverage exists; changing framework or test count doesn't enable branch coverage reporting.

4. Final Answer:

   Enable branchCoverage option in JaCoCo plugin settings -> Option D

5. Quick Check:

   Branch coverage = enable in JaCoCo config [OK]

Hint: Enable branchCoverage in JaCoCo config to track branches [OK]

Common Mistakes:

• Looking for annotations to enable coverage
• Thinking more tests auto-enable branch coverage
• Switching frameworks unnecessarily