From nexus-agents
Guides Test-Driven Development via Red-Green-Refactor cycle for new logic and Prove-It pattern for bug fixes. Ensures tests for features, edges, regressions.
npx claudepluginhub williamzujkowski/nexus-agentsThis skill is limited to using the following tools:
<!--
Enforces Test-Driven Development: write failing tests first, then minimal code to pass, refactor. For implementation tasks, bug fixes needing regression tests, behavior changes.
Enforces strict TDD for features and bugfixes: RED (write minimal failing test), GREEN (minimal passing code), REFACTOR. No production code without failing test first.
Enforces strict TDD workflow: Red (failing test), Green (minimal code), Refactor for features, bugfixes, refactors. Includes examples and verification steps.
Share bugs, ideas, or general feedback.
Full workflow: CONTRIBUTION_GUIDE.md. Prime directive: CLAUDE.md → Development Disciplines.
Skip TDD for:
When a bug is reported:
main — this proves the bug exists and your test is correctly sensitive.bug-fix skill for triage layering).pnpm test — to catch regressions the fix may have introduced elsewhere.The test stays as a regression guard. Future refactors can't silently re-break this case.
| Tier | Share | Latency | Scope |
|---|---|---|---|
| Unit | ~80% | milliseconds | single module, no I/O |
| Integration | ~15% | seconds | component interactions, may touch fs/db |
| E2E | ~5% | minutes | critical user flows end-to-end |
The Beyoncé Rule: "If you liked it, you should have put a test on it." Infrastructure changes don't catch behavioral bugs — your tests do.
| Principle | What it means |
|---|---|
| State-based assertions | Verify outcomes, not which methods were called. Refactoring-resistant. |
| DAMP over DRY | Tests are self-contained specifications. Duplicating setup is acceptable; cleverness in shared fixtures is not. |
| Real implementations > fakes > stubs > mocks | Mock at the network/process boundary, not within your own modules. |
| Arrange-Act-Assert | One scenario per test. Setup, action, assertion — clearly separated. |
| One assertion per concept | A test verifies one behavior. Multiple expect() calls are fine if they describe the same behavior. |
| Names read like specifications | it('returns 0 for an empty array') — not it('test1'). |
| Excuse | Counter |
|---|---|
| "I'll write tests after" | You won't. Post-hoc tests verify the implementation you happened to write, not the behavior you needed. |
| "Too simple to test" | Simple code becomes complicated. The test documents the expected behavior so future-you can refactor with confidence. |
| "Tests slow me down" | Tests slow the first hour and accelerate every hour after. The break-even is usually within the same PR. |
| "I tested manually in the browser/REPL" | Manual testing doesn't persist. The next change silently breaks it. |
| "Code is self-explanatory" | Code says how, tests say what and why-it-must. Without the test, the spec is in your head only. |
| "Just a prototype" | Prototypes become production. Prototype-without-tests becomes production-debt-with-bugs. |
main without the fix'calls saveToDatabase') instead of the behavior ('persists user across reloads').skip(), .todo(), or commented-out tests with no follow-up issuemain without the fixpnpm test.skip / .todo / disabled tests added in this PR (or each is linked to an issue)pnpm coverage (gate: 89.66% statements, 93.26% functions per CLAUDE.md)