← ClaudeAtlas

test-looplisted

Write tests, run them, and drive to green — either for existing code or full TDD (tests first, then implement until they pass). TRIGGER when the user says 'write tests for <file>, run them, and fix any failures', 'write tests for the <X> first, then implement it until they pass', 'add test coverage', 'TDD this', 'make the tests pass'. Hebrew: 'תכתוב טסטים ל...', 'תכתוב טסטים ותריץ עד שהכל ירוק', 'תעשה TDD', 'תוסיף כיסוי בדיקות', 'תריץ את הטסטים ותתקן'. Covers detecting the test framework, writing meaningful tests, running them, and iterating fix→run until pass. NOT for debugging one already-failing test in isolation (that's the debug skill's job, if you have it), NOT for load/stress testing (that's stress-test-setup's job, if you have it).
hiyabh/claude-skills · ★ 0 · Testing & QA · score 66
Install: claude install-skill hiyabh/claude-skills
# Test Loop — Write · Run · Fix Until Green ## Purpose Two related workflows around automated tests, both ending in a **green run**: - **Coverage mode** — write tests for existing code, run, and fix failures. - **TDD mode** — write the tests *first* from the spec, then implement the code until every test passes. **Language:** explanations in Hebrew; test code/comments in English. --- ## Step 0 — Detect the test setup (always first) - Identify the framework from the project: `package.json` scripts + devDeps (Jest, Vitest, Playwright, Mocha), `pytest`/`unittest` (Python), `go test`, `cargo test`, RSpec, etc. **Never assume** — read the config. - Find the run command (`npm test`, `pytest -q`, `go test ./...`) and the test file convention (`*.test.ts`, `*.spec.ts`, `test_*.py`, `_test.go`) and location. - If no test framework exists and the task needs one, propose + install the ecosystem-standard choice before writing tests, then scaffold minimal config. - Read an existing test file to **match style, imports, and patterns** exactly. --- ## Coverage Mode — tests for existing code Trigger shape: "write tests for `app/parsers/feed.py`, run them, and fix any failures". 1. **Read the target thoroughly** — understand its real behavior, inputs, outputs, error paths, and dependencies (what to mock vs. call for real). 2. **Write meaningful tests**, not filler: - Happy path(s) with representative inputs. - Edge cases: null/undefined, empty, zero, negative, boundar