Test Coverage Gap from Diff Prompt

This prompt is designed for QA engineers and developers who need to identify untested logic paths, missing edge cases, and regression risks before merging a pull request. It takes a code diff and the content of existing test files as input and produces a prioritized list of recommended new test cases. Use this prompt in CI/CD pipelines as a pre-merge gate, during manual code review to guide testing effort, or as part of a test planning workflow.

This prompt does not execute tests or measure code coverage metrics; it performs a static reasoning pass over the diff and existing tests to surface gaps that a coverage tool might miss, such as missing assertions for side effects, unvalidated error branches, and boundary conditions. The ideal input includes the full unified diff of the proposed changes and the relevant test file contents. For best results, provide the test files that correspond to the modified source files, not the entire test suite. The prompt works best with diffs under 2,000 lines; for larger changes, split the diff by module or component and run the prompt separately for each.

Do not use this prompt as a replacement for dynamic coverage instrumentation or mutation testing. It cannot detect gaps that require runtime profiling, such as race conditions that only manifest under load or integration paths that span multiple services. It also cannot verify that existing tests actually assert the correct behavior—only that they appear to exercise a code path. For high-risk changes, always pair this prompt's output with actual coverage reports and a manual review of test assertion quality. The prompt's recommendations are starting points for test authoring, not a certified safety net.

This prompt template is the core instruction set for the Test Coverage Gap from Diff workflow. It is designed to be pasted into your prompt layer, wired into a CI/CD pipeline, or used in a manual review tool. The template forces the model to reason about what changed, what is tested, and what remains exposed. Replace each square-bracket placeholder with the actual diff, test files, and output constraints before execution. The prompt is structured to produce a machine-readable JSON report, making it suitable for automated ingestion by test generation tools or QA dashboards.

textCopy
You are a QA automation engineer reviewing a code change. Your task is to analyze the provided code diff against the existing test files and identify untested logic paths, missing edge cases, and regression risks.

## INPUT
- Code Diff: [CODE_DIFF]
- Existing Test Files: [TEST_FILES]
- Change Context (optional): [CHANGE_CONTEXT]

## CONSTRAINTS
- Only flag logic paths that are introduced or modified by the diff.
- Do not flag pre-existing untested code unless the diff makes it riskier.
- For each finding, reference the specific file and line range from the diff.
- If a risk is high-severity (potential data loss, security, crash), mark it as `severity: critical`.
- If the existing tests already cover a path, do not include it.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "summary": "string (1-2 sentence overview of coverage gaps found)",
  "gaps": [
    {
      "id": "string (unique gap identifier, e.g., GAP-001)",
      "file": "string (file path from diff)",
      "lines": "string (line range, e.g., L45-L52)",
      "untested_logic": "string (description of the untested path or condition)",
      "risk": "string (severity: critical | high | medium | low)",
      "suggested_test": "string (description of a specific test case to add)",
      "existing_coverage_note": "string (why existing tests miss this, referencing specific test files if possible)"
    }
  ],
  "regression_risks": [
    {
      "area": "string (affected component or feature)",
      "risk_description": "string (what could break and how)",
      "related_gap_ids": ["string (list of gap IDs contributing to this risk)"]
    }
  ]
}

## INSTRUCTIONS
1. Parse the diff to identify all added or modified logic branches, conditions, loops, and exception handlers.
2. Cross-reference each identified logic path against the provided test files. Look for direct coverage and edge-case coverage.
3. For any path without adequate coverage, create a gap entry with a clear description and a concrete, implementable test suggestion.
4. Group related gaps into regression risk entries where multiple untested paths could interact to cause a failure.
5. If no gaps are found, return an empty gaps array and a summary stating that existing tests appear to cover the change.
6. Do not hallucinate test files or coverage that is not provided in the input.

After pasting this template, the primary adaptation points are the [CODE_DIFF] and [TEST_FILES] placeholders. The diff should be a unified diff format for best results. The test files should include the full content of relevant test suites, not just file names. If your test suite is large, pre-filter to files that import or reference the changed modules to keep context within token limits. The [CHANGE_CONTEXT] placeholder is optional but recommended for complex changes—use it to provide the PR description, linked issue, or developer intent. The output schema is designed for direct parsing; validate the JSON structure before forwarding results to your test generation pipeline. For high-risk repositories, always route severity: critical findings to a human QA lead for confirmation before acting on them.

The Test Coverage Gap from Diff Prompt is designed to be called programmatically as a step in your CI/CD pipeline, typically after a pull request is opened and the diff is available but before the change is merged. The harness must supply the raw unified diff as [DIFF] and the relevant test file contents as [TEST_CONTEXT]. The model returns a structured JSON payload containing a list of recommended test cases, each with a target logic path, suggested test name, and a risk priority. This output should be validated against a defined JSON schema before being posted as a comment on the PR or surfaced in your review dashboard.

To implement this, wrap the prompt call in a script that first extracts the diff from git diff origin/main...HEAD and gathers test files matching the changed source paths. The prompt should be sent to a capable model like claude-sonnet-4-20250514 or gpt-4o with response_format set to json_schema matching your expected output structure. Implement a retry loop with exponential backoff for transient API failures, but limit to three attempts. After receiving the response, run a strict validator that checks: (1) the JSON parses correctly, (2) each recommended test case has a non-empty logic_path, test_name, and priority field, and (3) priority values are within the allowed enum [CRITICAL, HIGH, MEDIUM, LOW]. If validation fails, append the validation errors to the prompt context and retry once. For high-risk repositories (e.g., payments, auth, safety-critical systems), always require a human to approve or dismiss each finding before the PR can be merged—this is not a replacement for human QA judgment.

Log every prompt call, response, and validation result to your observability stack with the PR ID, commit SHA, and model version as metadata. This enables trace analysis when a gap is missed and a regression reaches production. Avoid running this prompt on diffs larger than 10,000 lines without chunking by file or module; large diffs dilute the model's attention and produce lower-quality gap analysis. If the diff is too large, split it by changed module and run the prompt per module, then merge and deduplicate the results. The next step after implementing this harness is to build a regression test suite that measures the prompt's recall against known historical regressions where a test gap was the root cause.