domains / families / software-engineering / test-driven-development

test-driven-development

combined

Use when implementing any feature or bugfix, before writing implementation code Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. Use when asked to add tests to a function, fix a bug in it or change its behavior, even when the code is pasted inline and the request does not mention tests.

When to use

New features
Bug fixes
Refactoring
Behavior changes
Throwaway prototypes
Generated code
Configuration files
Implementing any new logic or behavior

When not to use

A passing unit test does not prove browser, packaged-runtime or provider integration behavior.
Retry examples assume retry-safe operations; production retries need explicit idempotency, cancellation and retryable-error policy.
Test-first order does not prevent incorrect requirements or over-mocking. Inspect assertions and real boundaries.
Preserve unrelated changes and use the project’s existing test commands rather than assuming every `npm test` accepts the same arguments.

Skill page

Conflict

The copies overlap heavily on the red-green-refactor loop, but they disagree on how to handle existing code and on the strictness of the 'test-first' rule. obra/superpowers and LeoYeAI/openclaw-master-skills enforce an 'Iron Law' where any code written before a failing test must be deleted. In contrast, sickn33/agentic-awesome-skills explicitly forbids deleting user work or resetting branches, instead advocating for characterization tests when implementation already exists. addyosmani/agent-skills adds a unique 'Discover the Stack First' step and a 'Prove-It Pattern' for bug fixes that the others lack. Because crowning one copy would either hide the 'delete code' rule or the 'preserve work' rule, a combined instruction is required.