tdd
npx machina-cli add skill fusengine/agents/tdd --openclawTDD Skill
Write the test first. Watch it fail. Write minimal code to pass.
The Iron Law
No production code without a failing test first.
Every line of production code must be justified by a test that failed without it. No exceptions. No shortcuts. No "I'll test after."
Agent Workflow
1. DETECT -> Identify stack, test framework, existing test patterns
2. RED -> Write ONE failing test for the next behavior
3. VERIFY -> Run test, confirm it fails for the EXPECTED reason
4. GREEN -> Write the SIMPLEST code that makes the test pass
5. VERIFY -> Run tests, confirm ALL pass (new + existing)
6. REFACTOR -> Clean up while keeping all tests green
7. REPEAT -> Next behavior = next failing test
CRITICAL: Never skip VERIFY steps. A test that passes on first run proves nothing.
RED-GREEN-REFACTOR Cycle
See references/red-green-refactor.md for the detailed cycle with rules and verification steps.
Reference Guide
| Topic | Reference |
|---|---|
| Full RED-GREEN-REFACTOR cycle | red-green-refactor.md |
| Common mistakes and red flags | anti-patterns.md |
| Per-stack test commands | stack-commands.md |
Quick Reference: Test Commands
| Stack | Run Tests | Watch Mode |
|---|---|---|
| React/Next.js | npx vitest run | npx vitest |
| Laravel | php artisan test | php artisan test --watch |
| Swift | swift test | - |
| Generic TS | bunx vitest run | bunx vitest |
| Go | go test ./... | - |
| Rust | cargo test | cargo watch -x test |
Forbidden Behaviors
- Never write production code before a failing test
- Never skip the VERIFY RED step
- Never accept a test that passes on first run without investigation
- Never mock what you can test directly
- Never write more than one test at a time in RED phase
- Never add features beyond what the current test requires
Source
git clone https://github.com/fusengine/agents/blob/main/plugins/ai-pilot/skills/tdd/SKILL.mdView on GitHub Overview
TDD is the practice of writing tests before production code. It enforces the Iron Law: no production code without a failing test. The workflow uses RED-GREEN-REFACTOR cycles to guide feature work and ensure safety during refactors.
How This Skill Works
Identify the stack and test patterns, then write a single failing test (RED). Run tests to confirm the failure, then write the minimal code to pass (GREEN). Re-run all tests, then refactor while keeping them green, and repeat for the next behavior.
When to Use It
- Adding a new feature with test-driven validation
- Fixing a bug where regression risk is high
- Refactoring code while preserving behavior
- Increasing test coverage for critical modules
- Aligning tests with a new or changed test pattern per stack
Quick Start
- Step 1: Detect the stack, test framework, and existing test patterns
- Step 2: In RED, write ONE failing test for the next behavior
- Step 3: Run tests, then implement the minimal production code to pass
Best Practices
- Always start with a failing test (RED) before touching production code
- Run the full test suite after each change to verify all tests pass
- Write the simplest production code needed to pass the test
- Never skip the VERIFY step; a quick pass is not enough
- Refactor with all tests green and without changing behavior
Example Use Cases
- Adding a new API endpoint by first writing a failing endpoint test, then implementing the handler
- Fixing a bug with a regression test to ensure it won’t recur
- Refactoring a utility module while keeping existing tests green
- Migrating a data model and validating compatibility with tests
- Introducing a new test framework pattern and updating tests accordingly
