Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →fbarrento/tdd
Test-driven development with red-green-refactor loop.
Passed 21 of 22 test cases with the skill, and 19 of 22 without it.
2 fixed19 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
I'm working on adding a recurring subscription feature to our billing service. Could you help me approach this using a proper test-driven development process? Please walk me through the necessary planning steps, interface considerations, and the sequence we should follow to write tests and implementation code.
| Checked | Without skill | With skill |
|---|---|---|
| Inquires about user preferences regarding public interface design prior to writing full implementation code. | Missed | Passed |
| Asks the user to specify which behaviors are most critical to test before implementation. | Missed | Passed |
The instructions your model reads when the skill loads.
Core principle: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.
Good tests are integration-style: they exercise real code paths through public APIs. They describe what the system does, not how it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.
Bad tests are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
See tests.md for examples and mocking.md for mocking guidelines.
DO NOT write all tests first, then all implementation. This is "horizontal slicing" - treating RED as "write all tests" and GREEN as "write all code."
This produces crap tests:
Correct approach: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.
WRONG (horizontal):
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
RIGHT (vertical):
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
...
test cases passed, vs 19 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.