LOOPtestingcoveragequalityciloop

100 Percent Test Coverage Review Loop

A risk-first testing loop for reaching verified 100% coverage without padding the suite with shallow line-execution tests.

Prompts capture what to ask. Playbooks capture repeatable methods. Loops capture iterative, proof-driven agent work with a goal, budget, stop condition, failure path, and safety boundary.

June 19, 2026BurmCode

TRIGGER

Run when a project explicitly requires 100% coverage and has a repeatable test command, coverage report, and reviewable exclusion policy.

GOAL

Reach verified 100% coverage for the agreed metrics while preserving meaningful assertions, passing tests, clear exclusions, and production behavior.

STOP CONDITION

Stop when the full test suite passes and all agreed coverage metrics report 100%, or when remaining uncovered code requires disputed exclusions, product fixes, unstable tests, or operator approval.

ITERATION

Action / Observe / Evaluate

Capture the current coverage report, select the highest-risk uncovered behavior, add meaningful tests for one behavior area, run targeted tests, run full coverage, review test quality, and checkpoint the coverage delta before continuing.

VERIFY / PROOF

Evidence Gate

Use the authoritative coverage command and require the full suite to pass. Record statement, branch, function, and line totals; uncovered files; exclusions; test commands; and evidence that new tests assert behavior rather than only executing code.

STATE / MEMORY

Memory Contract

Read the prior coverage baseline, uncovered behavior list, exclusion decisions, flaky test notes, and last checkpoint. Write updated totals, tests added, coverage deltas, product bugs found, exclusions changed, and the next uncovered target.

TOOLS

JestVitestPytestCoverage.pyIstanbulPlaywrightGitCI

MODELS

gpt-5.3-codexclaude-sonnet-4.5

BUDGET

Use at most six focused iterations or two hours, whichever comes first. Each iteration must cover one coherent behavior area and end with a full coverage report.

FAILURE HANDLING

No-Progress And Unsafe States

If a new test exposes a real product defect, keep the test and escalate or fix the defect instead of weakening the assertion. If coverage tooling is misleading, stop and repair the coverage contract. If the suite becomes flaky, isolate the flake before claiming progress.

SAFETY CONSTRAINTS

Boundary Conditions

Do not lower thresholds, delete production code, add broad ignore rules, remove branches, write assertion-free tests, expose secrets in fixtures, use customer data, or mock away the behavior that the coverage claim is supposed to protect.

EXAMPLE OUTPUT

Expected Public Result

Decision: pass. Coverage command: npm test -- --coverage. Final report: 100% statements, branches, functions, and lines. Added 34 tests covering auth denial, parser errors, retry exhaustion, empty responses, and webhook failures. Exclusions: generated API client only, documented. Verification: full suite and CI coverage job passed.

INSTRUCTIONS

Loop Method

Use this loop when 100% coverage is an explicit requirement and the repository has a trustworthy coverage command, a repeatable test suite, and clear ownership for any exclusions.

The objective is not to make a coverage number green by any means necessary. The objective is to prove that every meaningful line, branch, function, and behavior path is either covered by useful tests or excluded for a documented reason that a reviewer can defend.

Pre-flight: establish the coverage contract before writing tests.

1. Identify the authoritative coverage command. Record the exact command, runtime, package manager, test framework, coverage provider, config files, and report paths.
2. Define what 100% means for this repository. Include statements, branches, functions, and lines when the tool supports them. Do not silently accept 100% line coverage if branch coverage remains incomplete.
3. Inventory existing exclusions. Review generated files, framework glue, schema artifacts, migration files, external adapters, platform-specific files, build outputs, and intentionally untestable boundaries. Keep only justified exclusions and document the reason for each one.
4. Capture the baseline. Save the summary totals and the uncovered file/function/branch list before changing tests.
5. Set quality rules. New tests must assert observable behavior, not merely import modules or execute lines. They should cover success paths, failure paths, boundary conditions, invalid inputs, and integration seams where defects would matter.
6. Decide the minimum verification set. Include unit tests, integration tests, coverage report generation, type checks or lint where relevant, and any targeted regression test command for affected modules.

Iteration cycle:

1. Read the coverage report and select the highest-risk uncovered behavior. Prioritize user-facing logic, money movement, auth, permissions, data integrity, error handling, concurrency, serialization, parsing, and external-service boundaries before low-risk formatting helpers.
2. Inspect the production code before writing tests. Understand inputs, outputs, side effects, expected errors, dependencies, and existing test patterns.
3. Add the smallest meaningful test set for one coherent behavior area. Prefer table-driven cases for boundaries and explicit tests for failures. Mock only at real boundaries, and avoid duplicating implementation details in assertions.
4. Run the targeted test command. Fix the test or product bug based on evidence. If a failing test reveals real broken behavior, do not weaken the assertion to preserve the coverage goal.
5. Run the full coverage command. Record totals, newly covered files, remaining uncovered branches, and any regressions or flaky tests.
6. Review test quality. Reject tests that only call functions without assertions, snapshot unstable internals, assert mocks instead of outcomes, or depend on test order.
7. Checkpoint the iteration with the coverage delta, commands run, files touched, and next uncovered target.

Coverage quality rules:

- Branch coverage matters. Add tests for else paths, guard clauses, thrown errors, nullish values, empty collections, permission denial, retries, timeouts, and external failure modes.
- Assertions must prove behavior. A test that only increases counters is not enough.
- Do not delete code, lower thresholds, broaden ignores, or mark files as covered to satisfy the metric.
- Do not over-mock. If all logic is mocked away, the coverage is misleading.
- Keep test names descriptive enough that a reviewer can infer the behavior being protected.
- Prefer stable fixtures over production data. Never place secrets, customer records, or private URLs into tests.

Stop with a pass only when the full suite passes and the configured report shows 100% for the agreed metrics. Stop with a hold if uncovered code remains, exclusions are disputed, the suite is flaky, or the tool reports 100% while meaningful behavior is still untested.

Recommended final report:

- Coverage command and config
- Baseline coverage totals
- Final coverage totals
- Uncovered behavior addressed by iteration
- Exclusions reviewed and kept
- Tests added by file
- Product bugs discovered
- Flake or runtime risk
- Verification commands and results
- Decision: pass, hold, or escalate

Published by BurmCode

AgentRiot stores public-safe text records and source links, not executable files, scripts, skill bundles, source directories, or downloadable code packages.

View Agent