test-driven-development
Test-driven development. Use when asked to use TDD explicitly, or any other times when asked write a failing test before implementation, or similar.
When & Why to Use This Skill
This Claude skill facilitates a rigorous Test-Driven Development (TDD) workflow, enabling the agent to write failing tests before implementing features or bug fixes. It ensures high code quality, provides executable specifications, and minimizes regressions by validating every change against predefined test cases.
Use Cases
- Feature Implementation: Creating a new software module by first defining its behavior through failing unit tests to ensure the final code meets all specifications.
- Bug Resolution: Reproducing a reported issue with a specific failing test case to verify the bug exists before applying a targeted fix.
- Code Refactoring: Maintaining system stability during architectural changes by using a test-first approach to ensure existing functionality remains intact.
- Specification Validation: Using tests as a form of live documentation to clarify complex business logic before writing the actual production code.
| name | test-driven-development |
|---|---|
| description | Test-driven development. Use when asked to use TDD explicitly, or any other times when asked write a failing test before implementation, or similar. |
Test-driven Development
The point of test-driven development is to write a test that initially fails, to prove that a feature or bug exists in the first place, and to provide a sort of executable specification of the feature or bug. Then we implement the feature or bug fix. Then, without any changes to the test code, we re-run it and, if we have implemented correctly, it should pass.
Instructions
- First, fully understand the feature or bug. If there is any lack of clarity, ask questions about it until you have enough information to write a test, or set of tests. You also need to be sure where to write the test.
- Write the failing test that proves the feature is missing or the bug present. The test must FAIL RED. It MUST NOT be marked failing in code, or skipped. It is good, desired, and indeed the whole point of the exercise for the test to clearly fail. Also DO NOT write any comments in the test indicating that it is meant to fail. By the time it is committed, it isn't meant to fail! No modifications should be necessary at all to the test code before committing. User should explicitly approve the test.
- Run the test and see that it fails. If it passes, STOP.
- Implement the feature or bug fix that the test proves is missing. Implement only as much as the test can prove. It may be acceptable to make small accompanying fixes that other processes can prove are correct (for example, type-level code), but tend towards a small amount of code that only fixes what we are testing.
- Re-run the test we wrote. If it passes, SUCCCESS. If it fails, iterate on implementation until it does. If you keep iterating without success, STOP - there may be an issue with the test, or a deeper problem. Be sure to report back to the user with your progress.