Code coverage metrics in Software Engineering - Step-by-Step Execution

Concept Flow - Code coverage metrics

Write Code

↓

Write Tests

↓

Run Tests

↓

Collect Coverage Data

↓

Analyze Coverage Metrics

↓

Improve Tests if Needed

Back to Write Tests↓

Report Coverage

↩Back to Write Tests

This flow shows how code coverage metrics are collected by running tests on code, gathering data on which parts ran, analyzing it, and improving tests to cover more code.

Execution Sample

Software Engineering

function add(a, b) {
  return a + b;
}

// Test
add(2, 3);

A simple function is tested by calling it, and coverage tools track that the function and its return statement ran.

Analysis Table

Step	Action	Code Line	Coverage Data Collected	Coverage Status
1	Start test run	N/A	No coverage data yet	0% covered
2	Call add(2, 3)	function add(a, b) {	Function add entered	Function started
3	Execute return a + b;	return a + b;	Return statement executed	Line covered
4	Test call ends	}	Function add exited	Function fully covered
5	Collect coverage report	N/A	Function add: 100% lines covered	100% coverage
6	End test run	N/A	Final coverage data saved	Test complete

💡 Test run ends after all code lines executed by tests are recorded.

State Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Coverage Data	{}	{"function add": "entered"}	{"function add": "return executed"}	{"function add": "exited"}	{"function add": "100% covered"}

Key Insights - 3 Insights

Why does coverage show 100% even if tests only call the function once?

Because the test executed all lines inside the function during that call, as shown in execution_table rows 2-4, all code lines ran at least once.

What happens if a line of code is never run during tests?

Coverage data will mark that line as not covered, meaning tests missed it. This is seen by absence of coverage data for that line in execution_table.

Does code coverage guarantee bug-free code?

No, coverage only shows which code ran, not if tests check correct behavior. High coverage helps but tests must also verify correctness.

Visual Quiz - 3 Questions

Look at the execution_table at Step 3, what coverage data is collected?

A No coverage data yet

B Function add exited

C Return statement executed

D Final coverage data saved

💡 Hint

Check the 'Coverage Data Collected' column at Step 3 in execution_table.

At which step does the coverage report show 100% lines covered?

A Step 3

B Step 5

C Step 2

D Step 6

💡 Hint

Look at the 'Coverage Status' column for the step where full coverage is reported.

If the return line was never executed, how would the coverage status change?

A Function add would show partial coverage less than 100%

B Function add would show 0% coverage

C Coverage would still show 100%

D Coverage data would be empty

💡 Hint

Refer to key_moments about lines not run and partial coverage.

Concept Snapshot

Code coverage metrics track which parts of code run during tests.
Run tests to collect coverage data.
Coverage shows percent of code lines executed.
Use coverage reports to find untested code.
Improve tests to increase coverage and confidence.

Full Transcript

Code coverage metrics measure how much of your code runs when you run tests. The process starts by writing code and tests, then running those tests. As tests run, coverage tools record which lines and functions execute. After tests finish, coverage data is collected and analyzed to see what percent of code was covered. If coverage is low, you can add more tests to cover missing parts. Coverage helps find untested code but does not guarantee correctness. The example shows a simple function add(a, b) tested by calling it once. Coverage data tracks entering the function, executing the return line, and exiting. The final report shows 100% coverage because all lines ran. If some lines never run, coverage shows less than 100%, indicating tests missed those parts. This helps improve test quality and software reliability.

Practice

1. What does code coverage primarily measure in software testing?

easy

A. The number of developers working on the code

B. The number of bugs found in the code

C. The speed of the test execution

D. The percentage of code executed by tests

Solution

1. Step 1: Understand the purpose of code coverage

   Code coverage shows how much of the program's code is run during testing.

2. Step 2: Identify what code coverage measures

   It measures the percentage of code lines or branches executed by tests, not bugs or speed.

3. Final Answer:

   The percentage of code executed by tests -> Option D

4. Quick Check:

   Code coverage = executed code percentage [OK]

Hint: Code coverage = how much code tests run [OK]

Common Mistakes:

• Confusing coverage with bug count
• Thinking coverage measures test speed
• Assuming coverage counts developers

2. Which of the following is a common type of code coverage metric?

easy

A. Branch coverage

B. Memory coverage

C. Network coverage

D. User coverage

Solution

1. Step 1: Recall common code coverage types

   Common types include line coverage, branch coverage, and function coverage.

2. Step 2: Identify valid coverage types

   Branch coverage measures if all decision branches are tested; memory, network, and user coverage are not standard metrics.

3. Final Answer:

   Branch coverage -> Option A

4. Quick Check:

   Branch coverage is a standard metric [OK]

Hint: Branch coverage is a standard metric name [OK]

Common Mistakes:

• Choosing non-existent coverage types
• Confusing coverage with unrelated terms
• Ignoring common coverage categories

3. Consider a program with 100 lines of code. A test suite runs 80 lines and covers all branches in those lines. What is the approximate line coverage percentage?

medium

A. 20%

B. 100%

C. 80%

D. 50%

Solution

1. Step 1: Calculate line coverage

   Line coverage = (lines executed / total lines) x 100 = (80 / 100) x 100.

2. Step 2: Compute the percentage

   80 divided by 100 equals 0.8, multiplied by 100 gives 80% coverage.

3. Final Answer:

   80% -> Option C

4. Quick Check:

   80/100 = 0.8 = 80% [OK]

Hint: Divide executed lines by total lines, multiply by 100 [OK]

Common Mistakes:

• Confusing branch coverage with line coverage
• Calculating 100% because all branches covered
• Mixing up executed and total lines

4. A developer reports 90% code coverage, but some bugs remain. What is the most likely reason?

medium

A. High coverage does not guarantee all bugs are found

B. The coverage tool is broken

C. Tests ran too slowly

D. Code coverage measures bug count

Solution

1. Step 1: Understand code coverage limits

   Code coverage shows tested code amount but does not ensure test quality or bug detection.

2. Step 2: Identify why bugs remain

   Even with 90% coverage, tests might miss edge cases or logic errors causing bugs.

3. Final Answer:

   High coverage does not guarantee all bugs are found -> Option A

4. Quick Check:

   Coverage ≠ bug-free code [OK]

Hint: Coverage shows tested code, not bug absence [OK]

Common Mistakes:

• Assuming coverage means no bugs
• Blaming coverage tools without evidence
• Confusing coverage with test speed

5. You want to improve your test suite to cover all decision branches in a function with multiple if-else statements. Which approach best increases branch coverage?

hard

A. Write tests that only check the function's return value

B. Write tests that execute both true and false paths of each condition

C. Run the existing tests multiple times

D. Add print statements inside the function

Solution

1. Step 1: Understand branch coverage goal

   Branch coverage requires testing all possible paths of decision points (true and false).

2. Step 2: Choose the best testing approach

   Writing tests that cover both true and false branches ensures all decision paths run during testing.

3. Final Answer:

   Write tests that execute both true and false paths of each condition -> Option B

4. Quick Check:

   Branch coverage = test all decision paths [OK]

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

Common Mistakes:

• Testing only return values misses branches
• Rerunning tests doesn't increase coverage
• Adding print statements doesn't affect coverage