Coding
AI Prompt for Fixing Failing Tests
Fix failing tests without touching source code using this AI prompt: diagnose assertion vs behavior mismatches and repair the test correctly.
The prompt
Role: You are a test repair specialist. The SOURCE CODE is correct and must NOT change — only the test may be fixed. Context: Framework: [FRAMEWORK]. Failing test: [FAILING_TEST] Failure output: [FAILURE_OUTPUT] Source code (READ-ONLY): [SOURCE_CODE] Task: 1) Diagnose: is the test wrong (bad expectation, stale setup, wrong mock) or is it revealing a real behavior change? 2) If the test is wrong: fix it with the minimal change and explain the test author's misconception. 3) If it reveals a real behavior change: do NOT silently update the expectation — flag it as needing human review and explain what changed. 4) Suggest how to prevent this test failure class (better isolation, less brittle assertions). Format: Diagnosis first with a clear verdict (test bug vs behavior change), then the fix or the flag, then prevention. Constraints: NEVER modify [SOURCE_CODE]. NEVER update an expectation just to make the test pass without understanding why it differs — that hides regressions.
Variables to fill in
Replace each [variable] in the prompt with your own details:
[FRAMEWORK] [FAILING_TEST] [FAILURE_OUTPUT] [SOURCE_CODE]
Example input
FRAMEWORK=Jest, FAILING_TEST=test('applies discount', ...) expecting 90 got 100, SOURCE=discount.js (DO NOT CHANGE), ERROR=full assertion diff
How to use this prompt
State clearly whether source code may change — the default here is test-only fixes. Include the full assertion diff; the expected-vs-actual gap is the diagnosis.
Tips for the best results
- The 'test bug vs behavior change' verdict is the critical judgment — read it carefully.
- If it flags a behavior change, investigate the source before touching the test.
- Ask for the prevention tip; flaky-by-design tests will fail again.
Frequently asked questions
Can it change my source code?
Only with explicit permission — the default constraint forbids touching source, forcing the test to be the fix.
The test fails after a dependency update. What then?
Treat it as a behavior-change flag, not a test bug. The prompt's verdict step forces you to investigate the new behavior before touching expectations.