Removed Code Behavior

How Codecov handles status checks when you remove code.

How removed code behavior works:

Removed code behavior (RCB) is designed to help maintain a passing CI status so that developers can streamline their codebase without worrying about losing code coverage. In the development practice, code removal can be a good thing, however, removing entire lines can reduce the coverage percentage (which is affected if the ratio of total lines to total covered lines changes).

A few more things to note:

  • RCB applies to project coverage only. It doesn’t impact patch coverage.
  • RCB is effective only when the Target is set to auto.
  • RCB has 4 behaviors:
    • fully_covered_patch
    • removals_only
    • adjust_base (default behavior)
    • off

removed_code_behavior motivating example

Initial scenario:

  • Total lines in a project: 10
  • Covered lines in a project: 9

Action taken:

Developer removes 3 covered lines and adds 1 covered line. All changes are in a pull request.

  • Total lines in the project: 8
  • Covered lines in the project: 7 (3 covered lines removed, 1 covered line added)

Project coverage calculation:

  • The project coverage percentage is calculated as a ratio of covered lines to total lines in the coverage files. It calculates the percentage of lines covered by the combined test suite.

Initial calculation:

After removing 3 covered lines and adding 1 covered line:

removed_code_behavior options (with mathematical examples)

Option 1: fully_covered_patch

  • If the patch coverage is 100% and there are no unexpected changes, the project status should be: pass.

  • Indirect changes might be caused by modifications to both new and existing tests, covered and uncovered tests, processing errors, CI errors, and so on.

    Patch coverageIndirect changesCI statusScenario
    100%FalsePass statusIf the patch coverage % either increases, decreases, or remains equal to 100% with no indirect changes, the project status will pass.
    100%TrueFail statusIf the patch coverage % remains at 100% with direct changes, the project status will fail.
    < 100%TrueFail statusIf the patch coverage % either decreases or is less than 100% with indirect changes, the project status will fail.
    < 100%FalseFail statusIf the patch coverage % either decreases or is less than 100% with no indirect changes, the project status will fail.

When looking at the motivating example scenario, the project status check will always pass because the patch (the 1 line that was added) is 100% covered.

Option 2: removals_only

  • If changes are due to removed lines of code (i.e. no additions, no unexpected changes), the project status should be: pass
Lines removedLines addedIndirect changesCI statusScenario
TrueFalseFalsePass status-Lines removed
-No new lines added
-No indirect changes made
TrueTrueTrueFail status-Lines removed
-New lines added
-Indirect changes made
TrueTrueFalseFail status-Lines removed
-New lines added
-No indirect changes made
TrueFalseTrueFail status-Lines removed
-No new lines added
-Indirect changes made
FalseTrueTrueFail status-No lines removed
-New lines added
-Indirect changes made
FalseFalseTrueFail status-No lines removed
-No new lines added
-Indirect changes made
FalseTrueFalseFail status-No lines removed
-New lines added
-No indirect changes made
FalseFalseFalseFail status-No lines removed
-No new lines added
-No indirect changes made

When looking at the motivating example scenario, if status threshold is default/not set or automatic, the project status check will fail because 1 or more line has been added and coverage has decreased from 90% to 87.5%, a reduction of 2.5%.

Option 3: (Default) adjust_base

  • Recalculates the base to filter out any code removals. The recalculation removes misses, hits, and partials from lines removed in the diff of the base and uses that to calculate a comparison.

When looking at the motivating example scenario, if status threshold is default/not set or automatic, the project status check will pass because the project coverage has increased from an  adjusted_base of 85.7% to 87.5% (7/8 covered lines), an increase of 1.8%.

Option 4: False or off

  • This won’t add any special behavior to project statuses;
    When looking at the motivating example scenario, if status threshold is default/not set or automatic, the project status check will fail because project coverage has gone down from 90% to 87.5%, a reduction of 2.5%.
  • Project coverage decreases will always result in a failed status check in this case.