Fix Tests with AI
When a test fails, use Fix with AI to get a proposed patch you can review and apply—plus a fix-suggestion lifecycle that classifies whether the failure is a bad test or a product bug.
Overview
Fix with AI repairs a saved test on demand. It analyzes the test (using its last failed run when available), then proposes a patch with a classification, a confidence score, and a plain-language explanation shown as a per-field before/after diff. Nothing is written until you apply it. When the failure looks like a real API defect, the platform deliberately proposes no patch so the failure stays visible. Explore the capability at AI test fix.
Before you begin
- The test must be saved first—Fix with AI only appears for existing tests. On a new test you'll see "Save the test before using Fix with AI."
- Fix with AI is available to all users for saved tests; it's gated only by the
AI_TEST_FIX_ENABLEDflag (on by default) and a valid license. - Nav path: open a test in the test editor (from the endpoint tests table, click Edit on a row). The Fix with AI control sits at the bottom-left of the editor's action bar.
Step 1 — Invoke Fix with AI
- In the test editor, click the purple Fix with AI button (sparkle icon). While it works the label reads Fixing….
- To repair only part of the test, click the chevron next to the button and choose a target: Fix everything, Fix data, Fix body, Fix parameters, Fix assertions, or Fix authentication. The main button runs Fix everything.
- A modal titled Fix with AI opens showing "Analyzing the test and proposing a fix…" while the suggestion is generated.
Step 2 — Review the proposed patch
When the analysis returns, the modal shows a meta row and the diff:
| Element | What it tells you |
|---|---|
| Classification chip | Test defect, Data issue, Possible product bug, Environment issue, or Flaky. |
| Confidence: N% | How confident the model is in the proposed fix. |
| Used last failed run / Spec-based (no run) | Whether a prior failing run was used as evidence, or the fix is spec-only. |
| Explanation | A sentence describing what changed and why. |
| Diff | Per field: the path, the old value (red −) and new value (green +), with an optional reason line. |
If the classification is Possible product bug (or otherwise "do not fix"), the modal shows a warning instead of a diff: "This looks like a real API defect, not a test problem. The test was left unchanged so the failure stays visible. Investigate the API rather than editing the test." No Apply action is offered in that state.
Step 3 — Apply or discard
At the footer of the modal:
- Apply to form — loads the patched values into the editor so you can review, then save normally with Save Test.
- Apply & Save — applies the patch and saves the test in one step.
- Discard (or Close when there's no patch) — dismisses the suggestion without changing anything.
Identity fields (test ID, endpoint, endpoint ID, project ID, feature ID, API type) are never overwritten by a patch.
Step 4 — Handle a surfaced pending suggestion
When you open a test that already has a pending automated suggestion, the same Fix with AI diff modal appears with its classification, confidence, and diff. Applying it is resolved server-side (authoritative apply that also marks the suggestion applied), after which the editor closes so the list refreshes.
If the test was edited after the suggestion was created, the stored patch is stale: applying it returns HTTP 409 with "This test was modified after the suggestion was created. Re-run "Fix with AI" to get a fresh suggestion." (code SUGGESTION_STALE), and the suggestion is marked superseded. Re-run Fix with AI to get a current one. Applying or dismissing a suggestion that is already resolved also returns 409 ("Suggestion is already applied/dismissed").
Step 5 — Suggestion lifecycle and metrics
Fix suggestions are tracked so a team can triage them across a project:
- List — pending suggestions per project (or per test); a badge marks tests that have one.
- Apply — writes the patched test back and is audit-logged (recorded as an
ai_fix_suggestion_applyupdate). - Dismiss — closes a suggestion with an optional reason (up to 500 characters); captured as a learning signal.
- Metrics — totals by status and classification, acceptance rate (applied ÷ reviewed), and how many suspected product bugs were surfaced.
Applying and dismissing suggestions are learning signals that feed Continuous learning insights.
Troubleshooting
- "Save the test before using Fix with AI." — the test isn't saved yet; save it, then retry.
- 409 "This test was modified after the suggestion was created…" (SUGGESTION_STALE) — the patch is stale; re-run Fix with AI.
- Warning instead of a diff — the failure was classified as a product bug or environment issue and no safe patch was produced. Route product bugs to engineering rather than editing the test.
- Error toast (bottom-right) — the repair request failed; dismiss it and try again, or check AI configuration in AI Settings.
Best practices
- Read the classification first: a Possible product bug means the test may be correct and the API is wrong—investigate the API.
- Prefer applying high-confidence patches; review low-confidence ones closely before saving.
Related articles
Related articles
- Generate Endpoint Test Cases · Product documentation
- Open, Edit and Save Test Cases · Product documentation
- Test Configuration · Product documentation
- Execution Mode · Product documentation
- Run Tests and Review Results · Product documentation
- Test Generation Settings · Product documentation
Next steps
- Getting started · Install + connect your spec
- Configuration fundamentals · Stabilize runs
- Initial configuration · Users, licensing, projects
- Release notes · Updates and fixes
Still stuck?
Tell us what you’re trying to accomplish and we’ll point you to the right setup—installation, auth, or CI/CD wiring.