Coverage Enforcement

After running tests, GitAuto checks if code coverage reaches the target - 100% for new test files. It posts a coverage comment on the PR showing line, branch, and function coverage percentages. Uncovered lines are flagged and fed back to the agent so it can write additional tests to cover them.

Passing Tests Can Still Have Low Coverage

Without enforcement, tests that technically pass only cover the happy path. A function with five branches might get a test that exercises one of them, achieving 30% coverage while ignoring error handling, edge cases, and boundary conditions. The tests "pass" but provide minimal value.

Coverage enforcement creates a feedback loop: the agent writes tests, coverage is measured, uncovered lines are identified, and the agent iterates until the target is reached. This drives comprehensive test coverage rather than superficial test existence.

Why Models Only Test the Happy Path

Models have a strong bias toward generating the most obvious, straightforward test case. Testing error paths, edge cases, and boundary conditions requires adversarial thinking - imagining what could go wrong. Models default to "demonstrate the function works" rather than "prove the function handles failures." Without a feedback loop showing uncovered lines, the model considers its job done after one passing test. Training data and benchmarks reinforce this - most test examples in training data are happy-path tests, and code generation benchmarks only check "does the test pass," not "does the test cover edge cases."

How It Works

After the test runner finishes, GitAuto parses the coverage output to extract line, branch, and function coverage percentages for the source file being tested. For new test files (files that didn't exist before), the target is 100%. The coverage report identifies specific uncovered line ranges.

If coverage falls below the target, uncovered lines are sent back to the model with the source context, and another iteration begins. GitAuto also posts a coverage summary comment on the PR so reviewers can see the coverage achieved at a glance, even if 100% was reached and no manual review of coverage is needed.

Related Features

• Test Execution - runs the tests that produce the coverage data
• Untestable Detection - identifies code that cannot be covered, adjusting effective targets
• Dead Code Removal - removes unreachable code that would otherwise reduce coverage percentages