Flaky Test Hunter
Re-run your test suite to expose flaky tests, find the root cause of each one, fix it, and prove the fix with a long streak of consecutive passes.
Copy the Flaky Test Hunter loop
Stops when the suite passes a full streak of consecutive runs with no intermittent failures, or after 6 iterations. Edit the settings block, then paste the whole prompt into your agent.
You are running the "Flaky Test Hunter" loop. Settings (edit before running): - Test command: npm test - Repeat runs to detect flakes: 20 - Clean streak required: 30 consecutive passes - Max iterations: 6 Goal: find intermittently failing tests, fix their root causes, and prove each fix with a clean streak. Each iteration: 1. Run the test command repeatedly (use the runner's repeat or shuffle options if it has them). Record every test that fails at least once and how often. 2. Take the most frequent flaky test. Read it and the code it covers, and classify the cause: timing or sleeps, shared or leaked state, order dependence, real clock or timezone, unseeded randomness, or real network calls. 3. Fix the root cause. Prefer explicit waits, per-test setup and teardown, fake timers, fixed seeds, and local fakes for network calls. 4. Run that test file for the clean streak count. If it fails even once, the fix is not done. 5. Log: test name, failure rate before, cause, fix, streak result. Stop when: - A full detection pass finds no flaky tests. Success. - You reach the max iteration count. Rules: - Never add retries, increase timeouts as the only fix, or mark tests as skipped. - Do not delete assertions or loosen them to make a test pass. - If the flake is a real race in production code, fix it there and explain the bug. - Keep each fix limited to the flaky test and the code behind it. Final report: each flaky test, its cause category, the fix, and its before and after failure rate.
When this loop fits
- CI goes red at random and re-running the job is the team's standard fix.
- A test passes locally and fails in CI, or only fails when run with the rest of the suite.
- You are about to make the suite parallel and want to flush out shared-state bugs first.
What happens on each pass
The agent repeats these steps until the stop condition holds or it runs out of iterations.
- Expose the flake. Run the suite or the suspect file many times in a row, with random ordering if the runner supports it.
- Classify the failure. Group intermittent failures by cause: timing, shared state, test order, real time, randomness, or network.
- Fix the root cause. Replace sleeps with explicit waits, isolate shared state, freeze clocks, and seed randomness.
- Prove it. Re-run the fixed tests for a long streak and only count the fix when the streak is clean.
MCP servers for this loop
The 6 strongest of 900 matching servers, ranked by how closely they fit and then by trust score.
- 55Trust score 55 of 100, Fair
Testing MCP for coding agents: exercise real user journeys, find bugs, verify them with evidence.
RegistryLicenseQualityMaintenanceLicense: Not graded. No license is recorded for this server.Quality: Not graded. No README or tool list has been captured yet.Maintenance: Not graded. No commit or release date has been recorded. - 55Trust score 55 of 100, Fair
Scans live pages with the AudioEye rules engine and maps accessibility issues to JSX source.
RegistryLicenseQualityMaintenanceLicense: Not graded. No license is recorded for this server.Quality: Not graded. No README or tool list has been captured yet.Maintenance: Not graded. No commit or release date has been recorded. - 55Trust score 55 of 100, Fair
Local aggregate test-history stability analysis without test names or raw result contents. Tools...
RegistryLicenseQualityMaintenanceLicense: Not graded. No license is recorded for this server.Quality: Not graded. No README or tool list has been captured yet.Maintenance: Not graded. No commit or release date has been recorded.
52Trust score 52 of 100, FairApex by DRIP: A/B testing for online shops
Unknown author
A/B testing for online shops. Read results, build and preview test variations from chat.
RegistryRemoteLicenseQualityMaintenanceLicense: Not graded. No license is recorded for this server.Quality: Not graded. No README or tool list has been captured yet.Maintenance: Not graded. No commit or release date has been recorded.- 52Trust score 52 of 100, Fair
CHS Backflow — book backflow testing in Charleston
Unknown author
Book backflow testing in Charleston, SC: prices, ZIP coverage, free callback.
RegistryRemoteLicenseQualityMaintenanceLicense: Not graded. No license is recorded for this server.Quality: Not graded. No README or tool list has been captured yet.Maintenance: Not graded. No commit or release date has been recorded.
52Trust score 52 of 100, FairInbox placement tests across Gmail, Outlook, Yahoo and 30+ providers.
RegistryRemoteLicenseQualityMaintenanceLicense: Not graded. No license is recorded for this server.Quality: Not graded. No README or tool list has been captured yet.Maintenance: Not graded. No commit or release date has been recorded.
How to run this loop
- Connect the tools. Install a server the loop can use, for example Argus Testing — Autonomous QA MCP, or rely on your agent's built-in terminal and file access.
- Edit the settings block. Replace the example commands, targets, and limits with your project's own. Keep the iteration cap low on the first run.
- Paste it into an agent session. Start a fresh session in Claude Code, Cursor, or VS Code agent mode, in the repository root, and paste the prompt.
- Review before you merge. Read the final report and the diff. The loop leaves its work for you to review rather than shipping it.
Flaky Test Hunter questions
When does the Flaky Test Hunter loop stop?
It stops as soon as the suite passes a full streak of consecutive runs with no intermittent failures. It also stops after 6 iterations by default, or earlier when the prompt's own stop rules say it is stuck, and then reports what changed and what is left. Change the cap in the settings block at the top of the prompt.
Why not just add automatic retries to flaky tests?
Retries hide the symptom and keep the bug. A flaky test is either a broken test or a real race condition in your code, and retries make both harder to see. The loop treats retries as off limits so every fix addresses the cause.
How many passing runs prove a flaky test is fixed?
It depends on the failure rate. A test that failed one run in five almost certainly fails at least once in thirty runs if it is still flaky, so a clean streak of thirty is strong evidence. Raise the streak for rarer flakes.