Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →sickn33/tdd
Test-driven development.
Passed 19 of 22 test cases with the skill, and 15 of 22 without it.
and 4 more in the full report
5 fixed14 passed either way2 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
While planning a new billing calculation module, I want to ensure my interfaces are deep (small interface, deep implementation) and check for testability bottlenecks. What domain design approach should I reference?
| Checked | Without skill | With skill |
|---|---|---|
| Recommend consulting codebase design principles to evaluate deep modules and testability checks. | Missed | Passed |
The instructions your model reads when the skill loads.
Use when this workflow matches the user request: Use this skill for its documented workflow.
Source: mattpocock/skills (MIT).
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
test cases passed, vs 15 / 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.