Untested Code Path Identification Prompt

This prompt is designed for developers and QA engineers who need to analyze a single source file or module to find conditional branches, exception handlers, and loop boundaries that lack corresponding test cases. It is meant to be run before merging code, as part of a pre-commit or CI pipeline analysis step. The core job-to-be-done is producing a prioritized list of uncovered code paths with specific, actionable input suggestions that would trigger each path. This is not a replacement for a full coverage tool or a human code review. It is a focused analysis layer that reasons about reachability and test gaps at the path level, which line-coverage tools often miss because they can't distinguish between a covered line with untested branches and a truly exercised path.

To use this prompt effectively, you must provide the full source code of a single file or module as the [INPUT], along with any existing test file contents as [CONTEXT]. The model needs to see both the implementation and the tests to identify gaps. The ideal user is a developer who has just finished a feature or bug fix and wants to ensure they haven't introduced untested logic paths. The prompt works best on files with clear conditional logic—functions with if/else chains, try/catch blocks, loops with break conditions, and switch statements. It is less useful for purely declarative code, configuration files, or simple getter/setter methods where path coverage is trivial. Do not use this prompt on generated code, minified files, or code you don't have permission to analyze.

This prompt should not be used as a sole gate for merge decisions. It identifies potential gaps but cannot verify whether existing tests actually assert the correct behavior on those paths—it only checks for the presence of test coverage. Always pair the output with human judgment, especially for security-critical paths, authentication logic, and data integrity operations. The prompt also assumes that the provided test code is the complete test suite for that module; if tests are split across multiple files, you must aggregate them before running the analysis. For high-risk domains like financial transactions or healthcare data processing, require a second reviewer to validate each flagged gap before closing the issue. After running this prompt, take the prioritized list of uncovered paths and feed the highest-risk items into your test case generation workflow or manual test planning session.

The prompt below is designed to be dropped into your AI harness, CI pipeline, or local evaluation runner. It expects source code and a list of existing tests as input, then systematically identifies code paths that lack coverage. The output is a JSON array, making it straightforward to parse, validate, and feed into downstream test generation tools or ticketing systems.

textCopy
You are a test coverage analyst. Analyze the provided source code against the list of existing tests.

Identify every conditional branch, exception handler, and loop boundary that is not exercised by any existing test. For each uncovered path, provide a concrete input that would trigger it.

Return the results as a JSON array of objects with the following structure:
[
  {
    "file": "string (file path or module name)",
    "line_range": "string (e.g., '42-48')",
    "construct_type": "string (one of: conditional_branch, exception_handler, loop_boundary)",
    "uncovered_path_description": "string (what specific path is not tested)",
    "trigger_input": "string (concrete input that would exercise this path)",
    "risk_level": "string (one of: high, medium, low)",
    "rationale": "string (why this gap matters)"
  }
]

[SOURCE_CODE]
[EXISTING_TESTS]
[CONSTRAINTS]

Adapt the template by replacing the square-bracket placeholders. [SOURCE_CODE] should contain the full file or module under analysis. [EXISTING_TESTS] should list the test functions, methods, or cases that currently exist, including their names and the paths they cover if known. [CONSTRAINTS] is optional but useful for adding domain-specific rules, such as ignoring deprecated code paths, enforcing a minimum risk threshold for reporting, or limiting analysis to specific function scopes.

Before integrating this prompt into a production pipeline, validate the output against a known codebase with documented coverage gaps. Confirm that each returned object maps to a reachable code path and that the suggested trigger input would genuinely exercise it. For high-risk codebases such as authentication, payment processing, or safety-critical systems, always require human review of the identified gaps before generating remediation tickets. Avoid using this prompt as a standalone coverage gate; combine it with actual coverage tool data and static analysis results for a complete picture.

This prompt is designed to operate on a single file or module at a time, receiving the source code and optionally a coverage report or test file listing as context. The most reliable integration pattern is a pre-merge CI job that triggers when a pull request modifies files in watched directories. The harness should extract the diff, identify changed files, and invoke the prompt once per file with the full file content and the project's existing test manifest. For large files, consider splitting the file into logical sections (functions, classes) and running the prompt per section to avoid context window limits and improve precision. The prompt expects [SOURCE_CODE] and [EXISTING_TESTS] as inputs; the harness is responsible for assembling these from the repository state at the time of the PR.

Validation and output contracts are critical because this prompt produces structured findings that downstream tools consume. The harness must validate that each returned path includes: a reachable code location (file, line range, function name), the condition or branch that creates the untested path, a suggested input to trigger it, and a severity or priority ranking. Reject any finding that lacks a specific line reference or whose suggested input does not match the parameter types or constraints visible in the source. A second validation pass should deduplicate findings that describe the same code path with different phrasing. For high-risk codebases (auth, payments, data integrity), add a human review flag that prevents automatic merge if the prompt identifies CRITICAL severity gaps in security-sensitive modules.

Model choice and retry strategy matter here. Use a model with strong code reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because the task requires tracing control flow through conditionals, loops, and exception handlers. Set temperature to 0 or very low (0.0–0.1) to maximize deterministic output. If the output fails validation (missing fields, unparseable JSON, unreachable paths), retry once with the same input and a stricter system instruction that emphasizes the required schema. If the second attempt fails, log the failure, attach the raw output to the PR as a comment, and do not block the merge on this prompt alone—instead, surface it as a non-blocking advisory. For teams using tool-calling APIs, define a strict function schema for the output (e.g., list_uncovered_paths with typed fields for location, condition, suggested_input, severity) rather than relying on unstructured text parsing.

Logging and observability should capture: the file path, the prompt version, the model used, the number of findings returned, validation pass/fail status, and any retry attempts. Store these in your prompt observability system so you can correlate untested path findings with actual post-merge incidents over time. This data is essential for calibrating the prompt's severity scoring and reducing false positives. Do not use this prompt as the sole gate for merge decisions; combine its output with actual coverage tool data, static analysis results, and human code review. The prompt identifies likely gaps—it does not execute tests or measure coverage. Treat its output as a prioritized investigation list, not a definitive coverage report.