Why Line and branch coverage in JUnit? - Purpose & Use Cases

The Big Idea

What if your tests miss a hidden path that breaks your app in real life?

The Scenario

Imagine you have a big program with many decisions inside, like if-else statements. You try to check by hand if every line and every choice works correctly. You write tests, run the program, and guess if all parts were tested.

The Problem

Doing this by hand is slow and confusing. You might miss some lines or decisions without knowing. It's easy to think your tests are good when some parts never run. This can cause bugs to hide and surprise users later.

The Solution

Line and branch coverage tools automatically check which lines and decision paths your tests run. They show exactly what parts of your code were tested and what parts were missed. This helps you write better tests and catch hidden bugs early.

Before vs After

✗ Before

Run tests and guess coverage from logs and printouts.

✓ After

Use coverage tools to see colored reports showing tested lines and branches.

What It Enables

It makes sure your tests truly check every part of your code, giving you confidence your program works well.

Real Life Example

A developer fixes a bug in a payment system. Using branch coverage, they find a decision path never tested before, add a test for it, and prevent a costly error in real transactions.

Key Takeaways

Manual testing can miss code parts and hide bugs.

Line and branch coverage tools show exactly what code runs during tests.

This helps create stronger tests and more reliable software.

Practice

1. What does line coverage measure in JUnit testing?

easy

A. Whether the program runs without errors

B. Whether all possible input values are tested

C. Whether the test cases run in parallel

D. Whether each line of code is executed during tests

Solution

1. Step 1: Understand line coverage concept

   Line coverage measures if every line of code is executed at least once during testing.

2. Step 2: Compare with other options

   Options A, B, and D describe different testing aspects, not line coverage.

3. Final Answer:

   Whether each line of code is executed during tests -> Option D

4. Quick Check:

   Line coverage = executed lines [OK]

Hint: Line coverage = Did each line run? Check executed lines [OK]

Common Mistakes:

• Confusing line coverage with branch coverage
• Thinking line coverage checks input values
• Assuming line coverage means no errors

2. Which of the following is the correct JUnit annotation to mark a test method for coverage measurement?

easy

A. @Test

B. @Coverage

C. @RunCoverage

D. @Measure

Solution

1. Step 1: Recall JUnit test annotation

   The standard annotation to mark a test method in JUnit is @Test.

2. Step 2: Verify other options

   Annotations like @Coverage, @RunCoverage, and @Measure do not exist in JUnit.

3. Final Answer:

   @Test -> Option A

4. Quick Check:

   JUnit test method = @Test [OK]

Hint: JUnit test methods always use @Test annotation [OK]

Common Mistakes:

• Assuming coverage requires special annotation
• Using non-existent annotations
• Confusing coverage tools with JUnit annotations

3. Consider this Java method tested with JUnit:

public int max(int a, int b) {
  if (a > b) {
    return a;
  } else {
    return b;
  }
}

If your tests only call max(5, 3), what coverage is achieved?

medium

A. 100% line coverage, 100% branch coverage

B. 100% line coverage, 50% branch coverage

C. 50% line coverage, 100% branch coverage

D. 50% line coverage, 50% branch coverage

Solution

1. Step 1: Analyze lines executed by max(5, 3)

   Calling max(5, 3) executes the if condition and return a;, as well as the else block's closing brace, so all lines are executed, resulting in 100% line coverage.

2. Step 2: Analyze branches covered

   Only the 'if' branch (a > b true) is taken; the 'else' branch is not tested, so 50% branch coverage.

3. Final Answer:

   100% line coverage, 50% branch coverage -> Option B

4. Quick Check:

   One path = full line coverage, partial branch coverage [OK]

Hint: Test all if-else paths for full branch coverage [OK]

Common Mistakes:

• Thinking one test achieves 100% line coverage
• Confusing line coverage with branch coverage
• Ignoring else branch execution

4. You wrote tests for this method:

public boolean isPositive(int n) {
  if (n > 0) {
    return true;
  }
  return false;
}

But coverage report shows branch coverage less than 100%. What is the likely cause?

medium

A. Tests never call with n ≤ 0, missing else branch coverage

B. Tests have syntax errors causing incomplete runs

C. JUnit does not support branch coverage

D. Method has no branches to cover

Solution

1. Step 1: Identify branches in method

   The method has two branches: if (n > 0) true, else false.

2. Step 2: Understand branch coverage less than 100%

   If tests never call with n ≤ 0, the else branch is not executed, lowering branch coverage.

3. Final Answer:

   Tests never call with n ≤ 0, missing else branch coverage -> Option A

4. Quick Check:

   Branch coverage needs both if and else tested [OK]

Hint: Test both true and false conditions for full branch coverage [OK]

Common Mistakes:

• Assuming syntax errors cause coverage issues
• Believing JUnit lacks branch coverage support
• Ignoring else branch execution

5. Given this method:

public int classify(int x) {
  if (x > 0) {
    if (x % 2 == 0) {
      return 1;
    } else {
      return 2;
    }
  } else {
    return 3;
  }
}

What is the minimum number of JUnit test cases needed to achieve 100% line and branch coverage?

hard

A. 4

B. 2

C. 3

D. 5

Solution

1. Step 1: Identify branches

   There are three branches: outer if (x > 0) true and false, and inner if (x % 2 == 0) true and false.

2. Step 2: Determine test cases to cover all branches

   Tests needed: one with x > 0 and even (return 1), one with x > 0 and odd (return 2), and one with x ≤ 0 (return 3).

3. Final Answer:

   3 -> Option C

4. Quick Check:

   Three tests cover all branches and lines [OK]

Hint: Cover all if-else paths with minimal tests [OK]

Common Mistakes:

• Thinking two tests cover all branches
• Ignoring nested if branches
• Overestimating tests needed