Applying tdd
Skill narumiruna/skills/skills/workflow-repository/applying-tdd
npx -y skills add narumiruna/skills --skill applying-tddAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when implementing a non-trivial behavior change with Test-Driven Development (TDD) when practical: prove a focused failure, make the smallest passing change, then refactor safely.
SKILL.md
1.7 KB, as published. Nobody here has run it
Applying TDD
Use tests as executable behavior specifications, not as a coverage ritual.
Cycle
- Identify the smallest observable behavior that should change.
- Add or update the lowest-level meaningful test. Control time, randomness, network, storage, and other external inputs so the test is deterministic and isolated.
- Run it and confirm it fails for the intended reason. If it passes, correct the test or establish why another check is the valid red state.
- Implement the smallest change that makes the test pass. Do not weaken or delete a correct test to accommodate the implementation.
- Run the focused test, then relevant integration or end-to-end coverage and the repository gate.
- Refactor only while tests are green and without changing behavior.
For a bug, add a regression test when feasible. For a multi-path change, repeat the cycle in small observable increments rather than writing the entire implementation first.
Exceptions
Pure formatting, comments, behavior-preserving renames, exploratory spikes, and visual-only styling may not benefit from a red-first cycle. Requirements may also be too uncertain to encode safely.
When a non-trivial behavior change cannot start with a failing test, state:
- why the red state was impractical or unavailable
- how behavior was verified instead
- what risk remains
Finish with the behavior proved, the initial failure evidence when available, and the passing checks. Do not claim TDD merely because tests were added after implementation.