Test Environment Contamination Detection Prompt Template

Use this prompt when tests pass in isolation but fail in specific execution orders, when shared resources like databases, file systems, or environment variables appear corrupted between test runs, or when failure patterns correlate with test sequence rather than code changes. The prompt analyzes test execution order, shared resource access patterns, and failure correlation to detect environment contamination. It outputs contamination evidence with isolation recommendations. This is not a general-purpose test failure debugger—it targets the specific class of failures caused by leaked state, unreset fixtures, and cross-test pollution.

Do not use this prompt for simple assertion failures, code logic bugs, or performance regressions that are independent of test ordering. It assumes you have access to test execution logs, failure traces, and resource access patterns. Without execution order data and resource access logs, the prompt cannot establish causal links between test sequence and failure. If you only have isolated failure traces without ordering context, start with the Flaky Test Root Cause Analysis Prompt Template instead. This prompt also assumes a shared test environment—if your tests run in fully isolated containers with no shared state, contamination is unlikely and this analysis will produce false positives.

Before running this prompt, gather: a list of test executions with pass/fail status and timestamps, the execution order for failing runs, failure stack traces or error messages, and any available logs showing database state, file system contents, or environment variable values between tests. The more granular your resource access logs, the stronger the contamination evidence the prompt can produce. After receiving the output, validate contamination claims by attempting to reproduce the failure in the identified order, then verify that resetting the suspected shared resource between tests eliminates the failure. Use the isolation recommendations to add teardown hooks, transaction rollbacks, or resource scoping to your test harness.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to analyze test execution order, shared resource access, and failure correlation data to identify environment contamination between tests. Before using it, you must replace every square-bracket placeholder with real data from your test infrastructure. The prompt expects structured input—execution logs, resource access records, and failure histories—and returns a contamination evidence report with isolation recommendations. Do not run this prompt on raw, unprocessed logs; pre-process your data into the expected input format first.

textCopy
You are a test environment contamination analyst. Your task is to examine test execution data and identify evidence of environment contamination—where one test's side effects cause another test to fail or pass incorrectly.

## INPUT
[EXECUTION_LOG]: A JSON array of test execution records. Each record includes: test_name, start_time, end_time, status (PASS/FAIL/ERROR/SKIP), and execution_order_index.

[RESOURCE_ACCESS_LOG]: A JSON array of shared resource interactions. Each record includes: test_name, resource_type (FILE/DATABASE/ENV_VAR/NETWORK_PORT/MEMORY_CACHE/QUEUE), resource_identifier, operation (READ/WRITE/CREATE/DELETE/LOCK/UNLOCK), and timestamp.

[FAILURE_CORRELATION_DATA]: A JSON array of failure patterns. Each record includes: failing_test, co_failing_tests (tests that fail in the same run), historical_pass_rate, and recent_changes (list of recent code or config changes).

[CONSTRAINTS]:
- Only flag contamination when there is direct evidence of shared resource mutation followed by dependent behavior.
- Distinguish between correlation and causation. Do not claim causation without a clear resource dependency chain.
- If no contamination is detected, return an empty findings array with a summary explanation.
- Prioritize findings by severity: HIGH (causes false positives or false negatives in production-critical tests), MEDIUM (causes intermittent failures), LOW (causes only local or non-deterministic ordering effects).

[OUTPUT_SCHEMA]:
Return a JSON object with this exact structure:
{
  "summary": "string describing overall contamination assessment",
  "findings": [
    {
      "contamination_pair": {
        "source_test": "string",
        "affected_test": "string"
      },
      "resource_chain": ["ordered list of resource interactions showing contamination path"],
      "evidence": "string describing the specific evidence from the logs",
      "failure_pattern": "string describing how contamination manifests (false positive, false negative, flaky failure)",
      "severity": "HIGH|MEDIUM|LOW",
      "isolation_recommendation": "string describing how to isolate the tests (e.g., reset shared state, use unique namespaces, mock the resource, reorder test execution)"
    }
  ],
  "uncontaminated_failures": ["list of test names that failed but showed no contamination evidence"],
  "global_recommendations": ["list of environment-level isolation improvements"]
}

## ANALYSIS STEPS
1. Parse the execution log and identify all test failures.
2. For each failing test, trace backward through the resource access log to find tests that mutated resources the failing test later accessed.
3. Cross-reference with failure correlation data to confirm whether the pattern is consistent across runs.
4. For each contamination candidate, construct the resource chain showing the exact sequence of mutations and accesses.
5. Classify severity based on impact and reproducibility.
6. Generate specific isolation recommendations for each finding.
7. Identify failures that cannot be explained by contamination.

## IMPORTANT
- Base every finding on explicit evidence from the provided logs. Do not speculate.
- If the resource access log is incomplete, note this limitation in the summary.
- If execution order was randomized and contamination still occurs, flag this as a high-severity finding because randomization did not prevent it.

After pasting this template, replace each placeholder with real data. The [EXECUTION_LOG] should come from your CI/CD test runner (e.g., JUnit XML, pytest JSON report). The [RESOURCE_ACCESS_LOG] requires instrumentation—you may need to add logging around shared file handles, database transactions, environment variable mutations, and port allocations. If you lack resource access data, the prompt will still analyze execution order and failure correlation, but its findings will be limited to correlation rather than causation. Always validate the output against the [OUTPUT_SCHEMA] before surfacing results to your team. For high-severity findings, require human review before acting on isolation recommendations.

The contamination detection prompt is designed to operate as a post-execution analysis step in your CI pipeline, not as a real-time test runner. Wire it to trigger after test suite completion when failure patterns suggest state-dependent issues—typically when tests pass in isolation but fail in specific execution orders. The prompt expects structured input containing test execution logs, failure timestamps, shared resource access patterns, and the execution order. Feed this data from your test runner (e.g., pytest with --durations and --last-failed, JUnit XML reports, or custom harness output) into the [TEST_EXECUTION_DATA] placeholder. For large suites, pre-filter to only include failed tests and their immediate neighbors in the execution order to stay within context windows.

Validation and grounding requirements: The prompt output must be validated before any automated action is taken. Implement a post-processing validator that checks: (1) every claimed contamination pair includes specific evidence from the provided execution data—reject pairs that cite file paths, resource names, or timestamps not present in the input; (2) confidence scores are present and within 0.0–1.0 range; (3) isolation recommendations reference concrete mechanisms (e.g., database transaction rollback, temp directory cleanup, mock reset) rather than vague advice. If validation fails, retry once with the validation errors appended to the [CONSTRAINTS] field. On second failure, route to a human reviewer with the raw execution data and partial findings. Model choice: Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) for this task—contamination detection requires correlating patterns across multiple test cases, and smaller models frequently hallucinate causal links. Tool integration: If your test infrastructure exposes APIs for resource provisioning history or database state snapshots, include that data in [SHARED_RESOURCE_CONTEXT] to ground the analysis. For teams using Docker or Kubernetes test environments, include container lifecycle events and volume mount configurations.

Logging and observability: Log every prompt invocation with: test run ID, number of failures analyzed, contamination pairs found, validation pass/fail status, and reviewer assignment if escalated. Store these logs alongside your test result artifacts for post-incident review. Human review gate: Always require human approval before applying isolation fixes suggested by the prompt—changing test isolation strategies (e.g., adding database cleanup hooks, modifying shared fixture scopes) can mask real bugs or introduce new flakiness. The prompt's output should create a review ticket, not a direct commit. Avoid: Do not run this prompt on every CI build—reserve it for suites where flaky failure rates exceed a threshold (e.g., >5% of runs) or when on-call engineers explicitly trigger contamination investigation. Running it indiscriminately burns tokens and generates noise for stable suites.