IDE Test Repair Agent
Diagnoses failing tests, proposes a fix, and confirms it actually passes before showing it to you.
AI
Preview — early access.
Overview
A broken test suite is a dead end for most AI coding tools — they either can't see the failure or they "fix" it by guessing, with no way to know if the guess worked. The Test Repair Agent runs your test command, and if it fails, it diagnoses the failure, proposes a fix, and re-runs the tests with the fix temporarily applied to confirm it actually passes — before it ever shows you a diff. Nothing is written to disk permanently until you click Apply.
How it works
- Runs your test command (defaults to
npm run test, or scope it to a single file/pattern). - If it passes, you're done — nothing to repair.
- If it fails, the failure output goes to the same agent-session loop the AI editor uses to diagnose the cause and propose fixed file content.
- The proposed fix is applied temporarily, diffed against the real repo state, and the test command runs again to confirm the fix actually passes.
- The workspace is restored to its original state either way. You see the diff, the diagnosis, and a clear verified / not verified badge.
- You review and click Apply per file — the same apply path the AI editor uses — to write it for real.
Steps
- •
Open the Tests tab
In the Creytix IDE workspace, open the Tests tab (or pop it into its own window).
- •
Run & repair
Optionally scope the test command to a specific file, then click Run & repair.
- •
Read the verified badge
Green means the proposed fix was applied and a real re-run passed. Amber means it wasn't confirmed — review carefully before applying.
- •
Apply what you trust
Apply each proposed file individually. Nothing is written until you do.
Capabilities
- Real diagnosis, not a guess — the failure output is handed to the same explore-then-propose agent session the AI editor uses, with read access to the workspace.
- Verified before shown — the fix is temporarily applied and the test command re-run for real; "fixed" is never claimed without that re-run passing.
- Review, not silent apply — the workspace is always restored after verification; applying is an explicit, per-file human action.
- Scoped runs — point the test command at a single file or pattern instead of the whole suite.
Limits & honest scope
- Studio-tier tool: it proposes and verifies, it does not commit. Committing stays a separate, explicit action (Git tab).
- A "verified" fix can still be wrong in ways the test suite doesn't cover — it confirms the tests pass, not that the change is correct in every sense.
- Local-workstation only, same as the embedded terminal it runs on top of — disabled on hosted deployments.