Skip to content
Skills Library
Programming · Analysis

testing

/testing

Use for flaky or nondeterministic tests, especially local-vs-CI inconsistencies. Trigger on intermittent failures, race/timing symptoms, retry-only greens, or unexplained skip/xfail markers. Output should isolate reproducible cause, narrowest durable fix, and prevention guidance.

Repository
nexus ↗
Licence
MIT
Last repository change
30.09.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
4
Scripts
0
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 30.09.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What it does and when to use it

Use for flaky or nondeterministic tests, especially local-vs-CI inconsistencies. Trigger on intermittent failures, race/timing symptoms, retry-only greens, or unexplained skip/xfail markers. Output should isolate reproducible cause, narrowest durable fix, and prevention guidance.

Original author description

Use for flaky or nondeterministic tests, especially local-vs-CI inconsistencies. Trigger on intermittent failures, race/timing symptoms, retry-only greens, or unexplained skip/xfail markers. Output should isolate reproducible cause, narrowest durable fix, and prevention guidance.

How it works

  1. Core Principles
  2. Step 1 — Collect Context
  3. Step 2 — Classify Flakiness Type
  4. Step 3 — Reproduce
  5. Step 4 — Identify Root Cause
  6. Step 5 — Fix
  7. Step 6 — Prevention
  8. Output Contract
  9. Anti-Patterns (Quick Reference)
  10. Sub-documents
Original SKILL.md headings · 188 lines, 1,115 words
SKILL.md preview
---
name: testing
description: >
  Use for flaky or nondeterministic tests, especially local-vs-CI inconsistencies.
  Trigger on intermittent failures, race/timing symptoms, retry-only greens,
  or unexplained skip/xfail markers. Output should isolate reproducible cause, narrowest durable fix,
  and prevention guidance.
---

# Nexus Flaky Test Root Cause Analyzer

Structured protocol for diagnosing, isolating, and permanently eliminating non-deterministic test
failures. Not a retry wrapper — treats flakiness as a first-class defect.

```
name:             testing
category:         testing / quality
required_context: test file path, failure frequency, CI log or local output, stack trace if available
expected_inputs:  test name, framework, failure pattern, environment (local/CI/both), reproduction rate
expected_outputs: flakiness type, reproduction steps, root cause (one sentence), narrowest fix +
                  verification command, prevention recommendation
```

## Core Principles

1. A test failing 1-in-20 runs is still failing — it is a false alarm factory.
2. A retry without investigation ships unknown risk.
3. Fix the root cause, not the symptom — masking a race condition makes it fail more often.
4. Never mark `xfail`/`skip` without a linked issue and expiry date.
5. Test flakiness often mirrors a real production concurrency or data integrity hazard.
---

## Step 1 — Collect Context

Required before any investigation:

| Signal | How |
|--------|-----|
| Failure rate | Estimate from CI history (1/5? 1/100?) |
| Stack trace | Full verbatim trace from a failing run |
| Test path | Exact: `tests/users/test_create.py::test_create_user` |
| Framework + version | `pytest --version`, `jest --version`, `go version` |
| CI vs local | Fails only in CI, only locally, or both? |
| Parallelism config | `-n auto`, `--workers`, `t.Parallel()`? |
| Recent changes | `git log --oneline -10` on test file and its imports |

**If CI-only failure**, diff these before reading code: runtime version, OS/arch, parallelism,
`TZ` / NTP, network access, env vars (missing vars silently produce defaults), I/O speed, Docker layer cache.

---

## Step 2 — Classify Flakiness Type

| Type | Signature | Mechanism |
|------|-----------|-----------|
| Ordering | Fails after specific other tests; passes alone | Shared mutable state not reset |
| Timing | Fails on slow machines or under load | Hard-coded delays, no backoff, wall-clock assertions |
| Resource | Fails parallel, passes single-threaded | Port conflicts, shared temp dirs, DB row locks |
| Environment | Fails in CI only | Runtime delta, missing env var, OS behavior |
| External | Network errors, connection refused, timeouts | Real HTTP/DB calls in test |
| Concurrency | Assertion error varies each run; stack trace differs | Thread/async race, missing lock |

**Heuristic:**
- Fails when run alone → Timing / Resource / External / Concurrency
- Passes when run alone → Ordering (shared state from another test)
- Fails only in CI → Environment delta
- Failure message varies → Concurrency or External
- Fails more under parallel load → Resource contention or Concurrency

Record: `Primary: <type> | Secondary: <type or none>`

---

## Step 3 — Reproduce

Run at minimum 5 times before investigating. Confirm flaky, not consistently failing.

```bash
pytest tests/path/to/test.py::test_fn -xvs                          # alone, verbose
pytest tests/ --randomly-seed=last -x                                # ordering check
pytest tests/ -n auto -x                                             # contention check
for i in {1..20}; do pytest tests/path/to/test.py::test_fn -x --tb=no -q; done | grep -c FAILED
```

```bash
go test ./pkg/... -run TestFn -count=20 -v 2>&1 | grep -E "PASS|FAIL"  # Go
jest --testNamePattern "name" --runInBand --verbose                       # Jest
```

Record: X/N failed, fails alone or suite-only, rate under parallelism, verbatim stack trace.

---

## Step 4 — Identify Root Cause

**Ordering:** find unreset shared state — `grep -n "global\|@classmethod\|setUp\|tearDown\|autouse"`;
look for DB rows not rolled back, in-memory caches, module-level singletons, `scope="session"` fixtures.

**Timing:** `grep -rn "time.sleep\|asyncio.sleep\|setTimeout"` and polling loops without timeout;
look for fixed delays insufficient on slow machines, wall-clock assertions.

**Resource:** `grep -rn "port.*=[0-9]\{4,5\}\|localhost:[0-9]\{4,5\}"` and `grep -rn "tmp\|tempfile"`;
look for hardcoded ports, shared temp dirs, DB connections without rollback.

**Environment:** `cat .github/workflows/*.yml | grep -E "python-version|node-version|go-version"`;
compare env vars between local and CI.

**External:** `grep -rn "requests\.\|httpx\.\|fetch(\|http.Get"` and real DB connection strings in tests.

**Concurrency:** `grep -rn "threading\.\|asyncio\.\|goroutine"` and missing `Lock`/`Mutex`/`await`.

**State root cause as exactly one sentence:**
> *"test_X fails intermittently because Y when Z."*

If you cannot state it in one sentence, root cause is not yet identified.

---

## Step 5 — Fix

Apply the narrowest fix. Do not improve unrelated code.

| Type | Wrong fix | Correct fix |
|------|-----------|-------------|
| Ordering | Delete the interfering test | Add teardown resetting shared state after each test |
| Timing | Increase `time.sleep(N)` | Replace with `wait_for(condition, timeout=N)` |
| Resource | Manually assign different port | Use `port=0` or a `free_port()` fixture |
| Environment | Hard-code CI env locally | Parametrize via env var; test both modes in CI |
| External | Add retry in test | Mock external call; test real integration separately |
| Concurrency | Add sleep before assertion | Use lock, event, barrier, or join |

**Verification — required consecutive passes by failure rate:**

| Rate | Required passes |
|------|----------------|
| >20% | 20 consecutive passes |
| 5–20% | 30–50 consecutive passes |
| 1–5% | 50 consecutive passes |
| <1% | 100 passes or 30-day CI monitoring |

```bash
for i in {1..20}; do pytest tests/path/to/test.py::test_fn -x --tb=short -q; done
```

---

## Step 6 — Prevention

- **Ordering:** add `pytest --randomly-seed=random` to every PR; fixture teardown in PR template.
- **Timing:** add `wait_for(condition, timeout, poll_interval)` helper; flag new `time.sleep` in CI.
- **Resource:** add `free_port()` and `tmp_dir()` fixtures to conftest.py.
- **External:** enforce `--block-network` in unit tests; separate `@pytest.mark.integration`.
- **Concurrency:** shared `AsyncEventLoop` fixture; `asyncio_mode = "auto"` in pytest.ini.

---

## Output Contract

Every investigation closes with this report. Fill every field.

```
## Flaky Test Report

**Test:**             [full path + test name]
**Framework:**        [pytest / jest / go test / other]
**Failure Rate:**     [X/N runs]
**Primary Type:**     [Ordering | Timing | Resource | Environment | External | Concurrency]
**Secondary Type:**   [same options, or "none"]
**Root Cause:**       [one sentence — "test_X fails because Y when Z"]
**Why It Happens:**   [2–3 sentences — mechanism]
**Fix Applied:**      [file path + line numbers + change description]
**Verification:**     [command + result — "20/20 passes"]
**Prevention:**       [guardrail that stops this class from returning]
**Follow-up Needed:** [yes/no — if yes, describe]
```

---

## Anti-Patterns (Quick Reference)

- Do not add `time.sleep()` — masks the race, breaks on slower machines.
- Do not mark `xfail`/`skip` without a linked issue and target fix date.
- Do not retry in CI without investigating — retries hide failures.
- Do not close without a reproduction command in the ticket.
- Do not declare fixed after < required consecutive passes.

---

## Sub-documents

| Document | Purpose |
|----------|---------|
| `checklists/investigation-checklist.md` | Pre/during/post checklists for structured investigation |
| `anti-patterns/common-mistakes.md` | Common wrong fixes and why they fail |
| `validation/output-validation.md` | Fix confirmation, confidence scoring, escalation |
Files in this package (4)
  • SKILL.md 8 KB
  • anti-patterns/common-mistakes.md 1 KB
  • checklists/investigation-checklist.md 7 KB
  • validation/output-validation.md 3 KB

Versions

RepositoryScoreLicence
This page · aayushostwal/nexus100MIT
iuliandita/skills100MIT
wrongstack/wrongstack100MIT
langwatch/langwatch100Apache-2.0
mcouthon/agents100MIT
nteract/nteract100BSD-3-Clause
kettleofketchup/DraftForge100GPL-3.0
skillberry-ai/cap-evolve100Apache-2.0
TheBeardedBearSAS/claude-craft100MIT

Database snapshot: 13.11.2026 · package version c062c635e994 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100v1-e2e-testing
    Use when implementing or debugging browser end-to-end tests, especially Playwright or flaky tests. Triggers on "E2E test", "Playwright", or "flaky browser test".
  • 90Flaky Test Detector
    Detect, analyze, and fix flaky tests across any test runner. Use when tests intermittently fail in CI, tests pass locally but fail on CI, tests fail non-deterministically, or need to stabilize a flaky test suite. Also for 'flaky test', 'flaky', 'intermittent failure', 'unstable…
  • 84diagnose
    Diagnose and fix failing tests. Failure classification, root-cause analysis (never retry blindly), then the reproduce → isolate → fix → retest → regression loop. Use when: 'why does this fail', 'this test is failing', 'fix the failing tests', 'why is this test flaky', visible…
  • 100axiom-analyze-test-failures
    Use when the user mentions flaky tests, tests that pass locally but fail in CI, race conditions in tests, or needs to diagnose WHY a specific test fails.
  • 90absolute-deflake
    Flaky test fixes: detect nondeterministic tests empirically (repeat/shuffle/parallel runs), diagnose the root cause, fix it — never retry/skip/sleep — and verify across many randomized runs. Triggers on "absolute deflake", "fix flaky tests", "CI is flaky", "this test fails randomly/intermittently".
  • 90debugging-workflow
    Reproduce, isolate, and fix unexplained failures, regressions, or flaky behavior. Use when the cause is uncertain; a known-cause fix usually needs only the normal implementation workflow.

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.