OctiAI

Categories

Failing-Behavior → Machine‑Readable Test Suite (template)

Convert a failing behavior description or code excerpt into prioritized unit, integration, and regression tests plus a minimal fix plan.

What You'll Get

How to Use

High‑value prompt tweak

When you need executable tests rather than pseudocode, set `DETAIL_LEVEL` to include one concrete example test file and provide the single most relevant file path or failing test name. The assistant will then generate paste‑ready test code for that framework.

Works Best With

Use these prompt outputs when you can provide a small, focused code excerpt or the exact failing behavior + minimal environment details

Prompt Template


## Goal
- From a failing behavior description or a code snippet, produce an engineering-grade, machine-readable test suite and a minimal fix plan that enables fast triage, reproducible regression tests, and safe patching.

## Inputs
- Code excerpt or repo path: {{repo_root_path}}
- Programming stack / runtime (e.g., "node16 + express", "python3.10 + fastapi", "java17 + spring"): {{programming_stack}}
- Precise failing behavior description or failing input + error logs + stack trace or code snippet: {{failing_behavior_desc}}
- Preferred test framework(s) and test runner (single string, e.g., "pytest", "jest", "go test"): {{test_framework}}

If any of the above are missing, the prompt below will ask for the minimal missing artifacts and refuse to assume file contents or unseen files.

## Prompt
You are an expert software engineer and test author for {{programming_stack}}. Using only the provided repository context at {{repo_root_path}} and the failing behavior details in this request, produce an actionable diagnostic and a machine-readable test suite that reproduces the failure and prevents regressions.

Required outputs (produce all sections exactly as specified):

1) Assumptions/Unknowns — list any missing files, environment variables, or inputs you cannot see and that are required to run tests. For each unknown, state one precise minimal artifact or command the user must provide.

2) Reproduction Checklist (ordered, minimal steps) — exact commands, env vars, and inputs required to reproduce locally inside {{repo_root_path}}. Include expected error messages or failing assertions so CI can detect the failure.

3) Hypotheses (ranked by likelihood) — 3-6 concise root-cause hypotheses explaining the failing behavior. For each hypothesis include:
   - Why it would cause the failure (1-2 sentences).
   - Quick way to confirm or falsify it (one command or one targeted assertion change).

4) Diagnosis — based on the highest-likelihood hypothesis, describe the minimal code region(s) likely responsible (file paths and functions or logical components). Do not assume files you cannot see; if multiple candidates exist, list them with confidence scores.

5) Fix Plan (stepwise, minimal diffs) — a prioritized sequence of steps to implement a minimal patch that preserves behavior except to fix the failure. Each step must include:
   - One-line change description.
   - Files to modify (path).
   - Exact code-level change guidance (patch suggestion or one-line replacement) suitable for a human or an automated patch tool.
   - Rollback step and why it is safe.

6) Patch Suggestions — provide 2-4 concrete, minimal patch snippets (not full PRs) in the language idiom of {{programming_stack}}. For each snippet include:
   - Exact file path and function/method context line (where to insert/change).
   - The minimal code to add or change (follow the formatting of the target language).
   - A short rationale and any trade-offs.

7) Tests and Verification Checklist — produce a machine-readable test suite that includes:
   - Unit tests: for each test include exact test file path, exact test function name, test description, setup/mocks, input values, expected assertions, and any fixture schemas. Provide pseudocode or code sketch in the style of {{test_framework}} sufficient to paste into a test file.
   - Integration tests: for each test include endpoint/command to invoke, environment/setup steps, expected response or metric, and teardown.
   - Regression tests: a minimal fixture file content or JSON/YAML blob and the exact test that ensures the original failing input is covered.
   - Prioritization: mark each test as CRITICAL / HIGH / MEDIUM / LOW and explain why.
   - Coverage targets: list which lines/functions the tests must cover and the minimal metrics (e.g., "cover function X branches A,B").

8) Acceptance Criteria (for the fix) — precise pass/fail criteria that CI can assert: test names that must pass, performance/latency thresholds if relevant, and behavioral invariants to preserve.

9) Risk Checks and Mitigations — list possible regressions introduced by the fix and a short mitigation or verification step per risk.

10) Quick rollback commands — exact git commands or CI steps to revert the minimal patch if tests fail in CI.

Formatting requirements for your reply:
- Use numbered and bullet lists where appropriate.
- Use plain code-style inline for file paths, commands, test names, and exact strings.
- Provide test snippets in the idiomatic style of {{test_framework}} with clear placeholders for mocks or fixtures.
- Keep patches minimal; prefer targeted single-function edits over refactors.
- End with a short "next actions" list of 3 items the developer should run immediately after applying the patch.

Do not:
- Assume any unseen files or behavior beyond what is in {{repo_root_path}} and {{failing_behavior_desc}}.
- Propose broad refactors or design changes; keep changes scoped to the failure.

Produce the full response in machine-readable form following the "Output Format" section below.

## Output Format
Output:
  1) Assumptions/Unknowns
  2) Likely root causes (ranked)
  3) Fix plan (steps)
  4) Patch suggestions
  5) Test/verification checklist

Follow this ordering exactly and include the numbered labels above in your response.

## Guardrails
- Do not assume unseen files, test helpers, or CI scripts exist. If a helper is required, include it as an added minimal file in the patch suggestions.
- Prefer minimal diffs: single-line or single-function edits when possible.
- Avoid introducing new runtime dependencies unless absolutely necessary; explicitly call out any new dependency in Assumptions/Unknowns.
- If uncertain about environment (OS, DB version, runtime flags), ask for the single most important missing value and stop further changes.
- Always include rollback commands and one-step verification for each patch.

## Examples
- Mini example root-cause + fix excerpt:
  - Root cause: `null` returned from `getUser()` when upstream cache miss is unhandled.
  - Minimal fix excerpt (JavaScript): in `src/services/user.js` replace
    - `return cache.get(id)` 
    - with `const v = cache.get(id); return v == null ? await db.getUser(id) : v;`
  - Test name: `test_getUser_returns_from_db_on_cache_miss` (pytest/jest pseudocode included in Tests section).

Variables

Usage Notes

Not for

Do not include

Failing-Behavior → Machine‑Readable Test Suite (template)

Generate engineering-grade, machine-readable tests (unit, integration, regression), ranked root-cause hypotheses, a minimal patch plan, targeted patch snippets, and rollback steps from a failing behavior or code snippet.

Turn this into a working asset in minutes.

Import into Workspace to auto-fill variables, adapt output style, and iterate with OctiAI's prompt editor.

What you'll get

Output format

Markdown

Best used when

Avoid when

Sign in to save, like, or rate this prompt.

Made for

What to fill in

Use the guidance below to complete each placeholder with the right level of detail.

Repo Root Path

Provide the key details needed for this variable.

Programming Stack

Provide the key details needed for this variable.

Failing Behavior Desc

Provide the key details needed for this variable.

Test Framework

Provide the key details needed for this variable.

Rules

Canonical Examples

Input: Node16 + Express app: POST /users returns 500 when username contains emoji; stack trace shows `TypeError: Invalid header value`.

Loading result...

Failed to load output.


1) Assumptions/Unknowns: missing env vars (DB_URL), exact file paths (src/routes/users.js), start command.
2) Likely root causes (ranked): header construction with unescaped user input; body-parser or older dependency mishandling unicode; DB driver failing on emoji.
3) Fix plan: sanitize header usage, validate username input server-side, add test coverage.
4) Patch suggestions: small change in `src/routes/users.js` to avoid putting raw username into headers; add `utils/sanitizeHeader.js` helper.
5) Tests: Jest unit + supertest integration test `tests/users.emoji.test.js` posting emoji payload and asserting 400 or 201 as appropriate.

Why it works: This example demonstrates converting a runtime error and stack trace into a compact reproduction checklist, ranked hypotheses, minimal patch suggestions and a Jest test suite (unit + integration + regression) so engineers can reproduce, patch, and gate the fix in CI quickly.

Input: Python 3.10 + FastAPI + SQLAlchemy app: Intermittent deadlock on POST /orders under high concurrency; logs show `deadlock detected` when inserting/updating `inventory` rows.

Loading result...

Failed to load output.


Assumptions: provide `src/services/order.py`, DB URL, and whether sessions are per-request. Likely causes: missing row-level locking, long transactions, non-atomic inventory decrement. Fix plan: add SELECT FOR UPDATE in transaction, add retry-on-deadlock with exponential backoff. Tests: pytest unit tests mocking session and an integration concurrency test using multiprocessing to trigger deadlock.

Why it works: This example shows how to convert intermittent concurrency errors into a reproducible test suite (pytest) including a small integration test that reproduces deadlock under concurrency, ranked hypotheses, minimal code patches (SELECT FOR UPDATE / retry), and exact pytest snippets to gate the fix in CI.

Works Best With

Use these prompt outputs when you can provide a small, focused code excerpt or the exact failing behavior + minimal environment details