wolverin0 TDD Workflow
Use this skill when tests should shape the implementation or protect a risky change. Adapt to the project: do not force a framework, coverage target, or E2E suite that the repository does not already support.
Flow
- Read the existing test setup and conventions.
- Define the behavior in user-visible terms.
- Write the smallest failing test that captures the behavior or bug.
- Run the focused test and confirm it fails for the expected reason.
- Implement the smallest code change that makes the test pass.
- Run the focused test again.
- Broaden verification only as risk requires: related unit tests, integration tests, type checks, lint, build, or browser validation.
- Refactor only after tests are green.
Test Selection
- Unit tests for pure logic, components, validators, and utilities.
- Integration tests for APIs, database access, service boundaries, and auth.
- E2E/browser tests for critical user flows and UI regressions.
- Regression tests for every confirmed bug when feasible.
Rules
- Do not claim TDD if the first test was written after the implementation.
- Do not invent a test stack; inspect the repo first.
- Do not require 80% coverage unless the project already enforces it.
- Keep tests independent and deterministic.
- Mock external services at unit boundaries; use real integrations only when the project already has safe integration fixtures.
References
Load references/full-process.md when you need concrete Jest/Vitest,
Playwright, mock, coverage, or CI examples.
Output
TDD SUMMARY
Behavior: <what was specified>
Failing test: <path or not feasible>
Implementation: <paths changed>
Verification:
- <command>: <pass/fail>
Residual risk:
- <not covered>