Review test coverage and regression risk — procedure

Use this guide to review whether code, configuration, API, fixture, mock, or test changes are adequately covered by tests and protected against regression.

Engineering review workflow

Workflow summary

Review test coverage and regression risk after a code, configuration, API, fixture, mock, or test change

Expected result
What the workflow should produce
Produce a test-impact review that separates required test additions, optional improvements, missing evidence, and regression risks.
Best for
When this workflow fits
Code changes, API changes, configuration changes, fixture or mock updates, test setup changes, and regression-sensitive behavior that needs verification.

Purpose

This guide explains how to review whether a code, configuration, API, fixture, mock, or test change is adequately covered by tests. The workflow checks supplied implementation and test evidence, identifies missing scenarios or weak assertions, and marks unsupported findings as insufficient evidence instead of inventing test results.

When to use this

Use this section to decide whether this workflow is the right fit before you configure prompts, policies, or reference material.

Use case
A change may affect tested behavior
Use this when code, configuration, API contracts, fixtures, mocks, or test setup changed and the testing impact needs review.
Use case
Regression risk needs review
Use this when changed behavior may affect existing paths, edge cases, error handling, authorization, integration points, or regression-sensitive flows.
Use case
Test evidence is available
Use this when the user can provide implementation excerpts, changed files, test files, fixtures, mocks, logs, coverage output, or other evidence needed for a test-impact review.

Do not use this when

Use this section to prevent the workflow from being applied to the wrong source type, risk level, or implementation context.

Use a different review path
The main issue is architecture or boundaries
Use the architecture boundary review when the primary question is module ownership, dependency flow, state leakage, interface boundaries, or structural design.
Open architecture review
Use a different review path
The main issue is implementation against official guidance
Use the standards-backed implementation review when the primary question is whether code or configuration follows official documentation, standards, or vendor guidance.
Open standards review
Missing evidence
The supplied material does not include implementation or test evidence
Do not infer missing tests, coverage numbers, logs, defects, or pass/fail status. Ask for the missing implementation or test evidence.

Workflow controls

What this workflow controls

Use this section to understand which parts of the AI workflow are controlled by this guide before you configure prompts, files, or verification steps.

Instruction layer
Testing-impact review boundary
Defines the stable rule that the review is limited to test coverage, regression risk, assertions, fixtures, mocks, setup, cleanup, and verification impact.
Do not turn this workflow into architecture review or standards review unless that issue directly affects testing impact.
Reference layer
Implementation and test evidence
Defines the code excerpts, changed files, test files, fixtures, mocks, test data, configuration, logs, coverage output, and other evidence the review may inspect.
The workflow must not invent test execution results, coverage percentages, or defects that are not supplied.
Runtime prompt layer
Current change and review scope
Defines the current change, affected behavior, test evidence, constraints, and output requirements for the active review.
The current task should identify the change being reviewed and provide enough testing context.
Verification layer
Evidence-supported test findings
Checks that each coverage or regression-risk finding is supported by the supplied implementation or test evidence.
Unsupported findings must be marked as insufficient evidence.

Workflow placement

Where to configure this workflow

Place each part of the workflow in the correct layer before you run it. Keep stable rules out of one-off prompts, keep source material in the reference layer, and keep the current task in the runtime prompt.

Instruction layer
Stable test-review rule
Put the rule that the review is limited to test coverage and regression risk in the instruction layer when this workflow is reused.
Examples: ChatGPT Project Instructions · GPT Instructions · Skill instructions · Claude Project Instructions · Gem Instructions
Reference layer
Code, tests, and evidence
Put implementation excerpts, changed files, test files, fixtures, mocks, logs, coverage output, and relevant configuration in the reference layer.
Examples: ChatGPT project files or GPT Knowledge · Claude Project Knowledge · Gemini Gem Knowledge files
Runtime prompt layer
Current review request
Put the current change summary, target behavior, review question, constraints, and requested output format in the runtime prompt.
Examples: Current chat message · Task-specific prompt · One-time user request
Verification layer
Final evidence check
Check that every finding is supported by the supplied material and that unsupported areas are marked as insufficient evidence.
Examples: Verification checklist · Evidence gate · Confidence note

Platform mapping

Open the full platform mapping when you need tool-specific setup

Use this guide for the workflow-specific placement. Use the reference pages for the full ChatGPT, Claude, Gemini, and API setup mapping.

ChatGPT Projects, GPTs, Skills, files/sources, Custom Instructions, Memory, and runtime prompts. Open mapping → Claude Projects, Project Instructions, Project Knowledge, Skills, Claude Code surfaces, and runtime chat input. Open mapping → Gemini Gems, Gem instructions, Knowledge files, Memory, Connected Apps, AI Studio, Gemini API, Files API, File Search, and Vertex AI. Open mapping → API / internal systems System/developer instructions, retrieval, tools, orchestration, approvals, validation, evals, logging, and application state. Open mapping →

Workflow assets

Required workflow assets

Open the prompts, policies, and reference pages needed to run this workflow correctly.

Required prompt
Test coverage and regression review prompt
Runs the test-impact review and produces coverage gaps, regression risks, weak assertions, missing setup evidence, and concrete test additions.
Type: Workflow prompt
Belongs in: Runtime prompt layer
Use when: The task is to review testing impact after a code, configuration, API, fixture, mock, or test change.
Do not use when: The primary task is architecture review, standards-backed implementation review, security review, or general code-quality review.
Open prompt
Required policy
Choose a review policy for code or system design
Defines the routing boundary between architecture review, standards-backed implementation review, and test coverage / regression review.
Type: Engineering review policy
Controls: Review routing, scope selection, evidence handling, and unsupported-claim behavior.
Open policy
Required reference
Prompt layers and policy mapping
Explains where instruction rules, source material, runtime prompts, and verification gates belong.
Type: Configuration reference
Use when: Use when configuring the workflow in ChatGPT, Claude, Gemini, or an internal AI system.
Open reference

Implementation procedure

Step-by-step implementation procedure

Follow the workflow in order. Each step explains what to do, where it belongs, which asset to use, and what to check before continuing.

  1. Step 1 · Reference layer
    Provide the implementation change
    Attach or paste the changed files, code excerpts, configuration changes, API changes, fixtures, mocks, or test setup changes.
    What to do: Give enough context to identify what behavior changed and which components, interfaces, or test setup areas may be affected.
    Check before continuing: The change under review is explicit and tied to concrete files, excerpts, or configuration.
  2. Step 2 · Reference layer
    Provide the available test evidence
    Attach or paste relevant test files, assertions, fixtures, mocks, test data, setup and cleanup logic, logs, coverage output, or known regression-sensitive paths.
    What to do: Separate implementation evidence from test evidence so the review can compare changed behavior against existing coverage.
    Check before continuing: The supplied material shows what is currently tested and what evidence is missing.
  3. Step 3 · Runtime prompt layer
    Run the test-impact prompt
    Use the managed test coverage and regression review prompt to evaluate covered behavior, missing scenarios, weak assertions, and regression risks.
    What to do: Ask for required test additions, optional improvements, missing evidence, and confidence level.
    Use this asset: Test coverage and regression review prompt
    Check before continuing: The prompt is applied only to testing impact, coverage gaps, regression risk, and verification planning.
    Open prompt
  4. Step 4 · Verification layer
    Separate supported findings from missing evidence
    Check whether each finding is backed by the supplied implementation or test evidence.
    What to do: Mark unsupported claims as insufficient evidence instead of inventing test results, coverage numbers, logs, defects, or pass/fail status.
    Check before continuing: Every required test addition or regression risk is traceable to supplied material or explicitly marked as missing evidence.
  5. Step 5 · Verification layer
    Convert findings into required and optional actions
    Separate required test additions from optional test improvements.
    What to do: Prioritize missing tests that protect changed behavior, error paths, edge cases, authorization, integration points, and regression-sensitive flows.
    Check before continuing: The final review is actionable without overstating unsupported evidence.

Verification checklist

Use this checklist before accepting the output, publishing it, or using it as evidence for a downstream workflow.

Scope
The review stayed within testing impact
The output focuses on test coverage, regression risk, assertions, fixtures, mocks, setup, cleanup, and verification impact.
Evidence
Findings are supported by supplied material
Required test additions and risk findings are tied to provided code, configuration, test files, logs, coverage output, or explicit missing evidence.
Coverage
Important behavior paths were checked
The review considers positive paths, negative paths, edge cases, boundary cases, error paths, authorization/authentication paths, integration points, and regression-sensitive behavior when supported by the material.
Assertions
Assertions verify observable behavior
The review checks whether tests verify expected outcomes, not only execution without failure.
Setup
Fixtures, mocks, and test data are consistent
The review checks whether setup, cleanup, mocks, fixtures, and test data match the implementation changes.
Unsupported areas
Missing evidence is explicit
The output identifies missing files, logs, coverage data, or test evidence instead of inventing results.

Common mistakes

Use this section to avoid configuration errors, prompt-layer drift, source-boundary mistakes, and weak verification behavior.

Scope error
Using this workflow for architecture review
Architecture and boundary questions should use the architecture boundary review path unless they directly affect test coverage or regression risk.
Evidence error
Reviewing coverage without test files or coverage output
The workflow can identify missing evidence, but it cannot verify test coverage that was not supplied.
Assertion error
Treating execution without failure as coverage
A passing test is not enough if it does not assert the changed behavior or expected result.
Regression error
Ignoring affected adjacent paths
Changed behavior can require regression tests for integrations, configuration paths, authorization, data setup, and error handling.
Simulation error
Inventing test results
The workflow must not invent pass/fail status, coverage percentages, logs, defects, or executed test outcomes.

Workflow connections

Related resources

Use these resources when you need the related guide, prompt, policy, reference page, or background article that supports this workflow.

Related guides

Open these when the workflow needs an adjacent procedure or decision path.

Related guide · Decision guide
Code Review — choose the correct review path
Use this when you need to choose between architecture review, standards-backed implementation review, and test coverage / regression review.
Open chooser
Related guide · Alternative review workflow
Run the architecture boundary review
Use when the primary issue is structure, boundaries, ownership, dependency flow, state leakage, or architectural design.
Open architecture review
Related guide · Alternative review workflow
Run the standards-backed implementation review
Use when the primary issue is whether code or configuration follows official documentation, standards, or vendor guidance.
Open standards review

Related prompts

Open these when you need the managed prompt page, reusable prompt component, or protected execution prompt behind the workflow.

Related prompt · Related workflow prompt · Public
Review code against language and framework best practices
Use when the main task is implementation quality against language or framework best practices.
Belongs in: Runtime prompt layer
Open prompt
Related prompt · Related workflow prompt · Public
Plan a behavior-preserving code refactor
Use when the main task is to plan a refactor that preserves behavior while improving structure.
Belongs in: Runtime prompt layer
Open prompt

Related policies

Open these when you need the source boundary, evidence rule, refusal rule, or verification constraint behind the workflow.

Related policy · Alternative review policy
Review system architecture and boundaries
Use when the primary concern is architecture, module boundaries, ownership, dependency flow, or state leakage.
Controls: Architecture review scope and boundary checks.
Open policy
Related policy · Alternative review policy
Check implementation against official guidance
Use when the primary concern is implementation correctness against official documentation, standards, or vendor guidance.
Controls: Standards-backed implementation review scope.
Open policy

Related reference

Open these when you need configuration details, terminology, diagrams, or platform placement guidance.

Related reference · Site navigation reference
Content map
Use when you need the broader map of policies, prompts, guides, and reference pages.
Use when: You are deciding where this workflow sits in the site structure.
Open content map