# Test Driven Development

> Enforce Test-Driven Development discipline. Write failing test first, then minimal code, then refactor. Use when writing production code or implementing features. Do not use for debugging, documentation, or configuration tasks.

- Skill: `digi4care/test-driven-development` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add digi4care/test-driven-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/digi4care/test-driven-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- License: MIT
- Author: digi4care (https://skillmd.com/u/digi4care)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/digi4care/test-driven-development

---


# Test Driven Development

## When to Use Me

Use me when:

- write production code
- add feature
- implement
- TDD
- new function
- create endpoint
- add method
- implement this
- write code for

Do not use me for:

- debug
- investigate
- analyze error
- refactor without changing behavior
- documentation
- configuration
- setup
- explore
- spike
- general programming questions
- installation or troubleshooting
- framework-agnostic code help
- bug investigation (use systematic-debugging first)

## Workflow

1. Identify behavior to implement
2. Write failing test (RED) - one behavior, clear name, real code
3. Verify test fails correctly - MANDATORY, never skip
4. Write minimal code to pass (GREEN) - simplest possible
5. Verify all tests pass - MANDATORY, check other tests too
6. Refactor while staying green (REFACTOR) - clean up only
7. Repeat for next behavior

## Error Handling

- Code written before test exists: STOP, request deletion, restart with test
- Test passes immediately: Verify test tests the right thing, not existing behavior
- Multiple behaviors in one test: Ask to split into separate tests
- Refactoring with failing tests: STOP, require green tests first
- I'll test after: STOP, TDD requires test first - no exceptions
- Keeping code as reference: STOP, delete means delete

## Tools

The following tools are available to enforce TDD:

- `check-test-exists` - Verify test file exists before writing implementation
- `validate-tdd-cycle` - Check if TDD cycle was followed via git history
- `analyze-git-order` - Analyze commit order to verify test-first approach

Use these tools to validate TDD compliance automatically.

## Quick Tests

Should trigger:

- Create a new API endpoint
- Add user authentication
- Implement a new endpoint with tests first
- Implement payment processing
- Write a login function

Should not trigger:

- Debug this error
- Investigate why tests fail
- Refactor this function (no behavior change)
- Update the documentation
- Configure the server

Functional:

- Write test before implementing login feature
- Follow TDD for new endpoint

## References

- `references/workflow-playbook.mdx` - RED-GREEN-REFACTOR cycle details
- `references/anti-patterns.mdx` - Testing anti-patterns to avoid

## The Iron Law

```
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
```

Write code before the test? Delete it. Start over.

## Verification Checklist

Before marking work complete:

- [ ] Every new function/method has a test
- [ ] Watched each test fail before implementing
- [ ] Each test failed for expected reason
- [ ] Wrote minimal code to pass each test
- [ ] All tests pass
- [ ] No errors or warnings in output
- [ ] Edge cases covered