Retry and Timeout Behavior Test Prompt

This prompt is built for SREs and backend engineers who need to validate resilience patterns directly from production source code. The job-to-be-done is turning raw code snippets containing retry logic, timeout configurations, and backoff strategies into structured, actionable test scenarios. The ideal user is someone who can provide the relevant code blocks and a map of service dependencies, and who needs to expose idempotency violations, cascading failure risks, and misconfigured timeout chains before they cause incidents. The required context includes the code under review, the service dependency graph, and any known infrastructure-level retry behavior that might interact with application-level logic.

Do not use this prompt for general unit test generation or for systems where retry behavior is handled entirely by infrastructure layers outside the codebase, such as a service mesh or API gateway that manages retries transparently. It is also not suitable for generating load tests, performance benchmarks, or security fuzzing inputs. The prompt assumes that retry and timeout logic is visible in the application code and that the reader can articulate the expected failure modes of downstream dependencies. If the codebase uses a library or framework that abstracts retry behavior, provide the configuration or decorator usage rather than expecting the model to infer it from imports alone.

Before running this prompt, gather the relevant code snippets, identify the service boundaries, and document any known idempotency guarantees or lack thereof. The output will be a structured test plan, not a passing test suite. You will need to implement the scenarios in your testing framework and validate them against your actual infrastructure. For high-risk systems where retry misbehavior could cause data corruption or financial impact, always include a human review step before executing generated test scenarios in production-like environments.

This template is designed to be copied directly into your AI coding agent or test generation pipeline. It instructs the model to analyze retry logic, timeout configurations, and backoff strategies in your codebase and produce structured test scenarios that expose idempotency violations, cascading failure risks, and misconfigured resilience patterns. Replace each square-bracket placeholder with your specific context before use.

codeCopy
You are a resilience testing engineer analyzing retry, timeout, and backoff behavior in a production codebase. Your task is to generate structured test scenarios that validate the correctness and safety of resilience patterns.

## INPUT
Source code files to analyze:
[CODE_FILES]

Configuration files containing timeout and retry settings:
[CONFIG_FILES]

Dependency graph or service topology:
[SERVICE_DEPENDENCY_MAP]

Existing test patterns to follow:
[EXISTING_TEST_EXAMPLES]

## CONSTRAINTS
- Target language and test framework: [TEST_FRAMEWORK]
- Maximum test execution time per scenario: [MAX_EXECUTION_TIME_MS]ms
- Required coverage: all retry paths, timeout boundaries, backoff strategies, and circuit breaker states
- Do not generate tests that require external network access
- Tests must be deterministic and repeatable
- Flag any idempotency concerns with severity HIGH, MEDIUM, or LOW

## OUTPUT_SCHEMA
Return a JSON array of test scenarios with this structure:
{
  "scenarios": [
    {
      "scenario_id": "string",
      "category": "retry | timeout | backoff | circuit_breaker | idempotency",
      "target_function_or_endpoint": "string",
      "description": "string",
      "preconditions": ["string"],
      "test_input": "object describing input or trigger",
      "expected_behavior": "string",
      "assertions": ["string"],
      "failure_mode_tested": "string",
      "idempotency_risk": "HIGH | MEDIUM | LOW | NONE",
      "cascading_failure_risk": "HIGH | MEDIUM | LOW | NONE",
      "test_code_skeleton": "string containing the test function stub",
      "mocks_required": ["string"],
      "timeout_config_under_test": "string or null"
    }
  ],
  "global_risks": [
    {
      "risk_type": "string",
      "location": "string",
      "severity": "HIGH | MEDIUM | LOW",
      "description": "string",
      "recommendation": "string"
    }
  ],
  "coverage_summary": {
    "retry_paths_found": "number",
    "timeout_configs_found": "number",
    "backoff_strategies_found": "number",
    "circuit_breaker_patterns_found": "number",
    "untestable_paths": ["string"]
  }
}

## TOOLS
You may use the following tools during analysis:
[AVAILABLE_TOOLS]

## RISK_LEVEL
This analysis targets [TARGET_ENVIRONMENT] where failures can cause [BUSINESS_IMPACT]. Flag any scenario where a test failure indicates a production outage risk.

## EXAMPLES
Here are examples of the expected test scenario format:
[FEW_SHOT_EXAMPLES]

Begin analysis.

After copying the template, fill in the placeholders with your specific context. For [CODE_FILES], include the source files containing retry logic, HTTP clients with timeout settings, message queue consumers, or database connection pools. For [CONFIG_FILES], provide YAML, JSON, or environment-based configuration that sets timeout values, retry counts, and backoff multipliers. The [SERVICE_DEPENDENCY_MAP] should describe which services call which, so the model can trace cascading failure paths. If you have existing test examples, include them in [EXISTING_TEST_EXAMPLES] so the generated tests follow your team's conventions. The [FEW_SHOT_EXAMPLES] placeholder is critical for output quality—provide two or three well-formed scenario objects that demonstrate your expected level of detail and assertion style. For high-risk production systems, set [RISK_LEVEL] context explicitly and ensure a human reviews the generated scenarios before they enter your CI pipeline.

This prompt is designed to be executed automatically within a CI pipeline or as part of a manual pre-production resilience review. It takes a code diff, a target function signature, or a service configuration block as input and produces a structured test plan. The primary integration point is a step that runs after static analysis but before deployment to a staging environment. The prompt's output is not executable code; it is a JSON specification of test scenarios that must be parsed and fed into your existing test execution framework.

To wire this into an application, build a harness that performs the following steps: First, extract the relevant source context—this could be a git diff output, a specific file path, or a parsed AST snippet—and inject it into the [CODE_OR_CONFIG] placeholder. Second, inject the [SERVICE_CONTEXT] with known dependencies, such as database connection strings or downstream service names, to enable the model to reason about cascading failures. Third, define a strict [OUTPUT_SCHEMA] in the prompt, such as a JSON array of objects with fields for test_name, failure_mode, assertions, and risk_level. After receiving the model's response, validate it against this schema programmatically. Any output that fails schema validation should trigger a retry with a more explicit error message appended to the prompt, up to a maximum of two retries. For high-risk services, route the validated test plan to a human reviewer via a pull request comment or a ticketing system before any load test is generated from it.

The most common production failure mode is the model generating a test for a timeout configuration that doesn't exist in the provided code, a hallucination often caused by the model's pre-training on common library defaults. Mitigate this by adding a [CONSTRAINTS] block that explicitly instructs: 'Only generate tests for retry and timeout configurations explicitly visible in the provided code. Do not assume default values for any library.' A second failure mode is the generation of non-idempotent test scenarios for message queue consumers or payment endpoints. Your harness must run a secondary validation pass using a separate, smaller classifier model or a regex-based check to flag any generated test that performs a state-changing operation without a corresponding idempotency key or a unique identifier. Flagged tests should be blocked from automatic execution and sent for human review.

For model choice, a mid-tier reasoning model like claude-3.5-sonnet or gpt-4o provides a good balance of code comprehension and structured output adherence. Avoid smaller, faster models for this task, as they frequently confuse backoff strategies (e.g., exponential vs. linear jitter) when described in code. Log the full prompt, the raw model response, the schema validation result, and the final parsed test plan as a single trace object. This trace is invaluable for debugging false positives in the idempotency check or for tuning the prompt's constraints over time. The next step after generating this test plan is to feed the validated JSON into a test scaffold generator that produces the actual pytest or k6 script, but that is a separate prompt's responsibility.