Making your code base better will make your code coverage worse

Why has code coverage become the go to metric for code quality?

Code coverage, once a helpful tool for identifying gaps in testing, has increasingly become a proxy for code quality, despite a lack of scientific evidence linking the two. The author’s experiment revealed that blindly applying an 80% coverage threshold can lead to suboptimal decisions, such as prioritizing tests for low-value features and artificially inflating coverage scores.

Why This Matters

The widespread adoption of code coverage as a key metric overlooks the nuances of software development and the varying importance of different code sections. Relying solely on this metric can lead to wasted resources, increased development time, and a false sense of security, potentially costing companies time and money without significantly improving software reliability.

Key Insights

• Pareto Principle Misapplication, 2025: The commonly used 80% threshold is likely derived from a misunderstanding of the Pareto principle, which doesn’t advocate for equal coverage across all code.
• DRY Code & Coverage: Making code more DRY (Don’t Repeat Yourself) can paradoxically decrease code coverage due to consolidation of tested code blocks.
• Verbose Code & Accuracy: More explicit and verbose code structures can lead to more accurate code coverage metrics, revealing true gaps in testing.

Working Example

// condition_control.js
export const conditionControl = (x, y, z) => {
  return x || y || z;
};

// conditionSwitchSeparate.js
export const conditionSwitchSeparate = (x, y, z) => {
  switch (true) {
    case x:
      return true;
    case y:
      return true;
    case z:
      return true;
    default:
      return false;
  }
};

//Unit test for the control function
import { conditionControl } from "./condition_control";
describe("validate function conditionIfElse", () => {
  it("should return true when X is true and other params are false", () => {
    const xIsTrue = conditionControl(true, false, false);
    expect(xIsTrue).toBe(true);
  });
  it("should return true when Y is true", () => {
    const yIsTrue = conditionControl(false, true, false);
    expect(yIsTrue).toBe(true);
  });
  it("should return true when Z is true", () => {
    const zIsTrue = conditionControl(false, false, true);
    expect(zIsTrue).toBe(true);
  });
  it("should return false when all params are false", () => {
    const allFalse = conditionControl(false, false, false);
    expect(allFalse).toBe(false);
  });
});

Practical Applications

• Financial Institutions: Prioritize high code coverage for critical transaction processing code, while accepting lower coverage for less sensitive features like user profile customization.
• Pitfall: Blindly enforcing 80% coverage across all code, leading developers to write trivial tests simply to meet the threshold, rather than focusing on thorough testing of core functionality.

References:

• https://stackoverflow.blog/2025/12/22/making-your-code-base-better-will-make-your-code-coverage-worse/