dckcandClaude Opus 5.5
fe9ad200c4
Name the skill for what triggers it. Cite Wikipedia on capability-based security and ambient authority, and point newcomers to awesome-ocap. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2.4 KiB
name, description
| name | description |
|---|---|
| lazy-tdd | Lazy TDD / test-driven debugging — use when a bug, goof, regression, or "that didn't work" is discovered in code you wrote; when fixing a failing behavior; when refactoring; or when deciding whether new code needs tests. Code that works the first time may ship untested; a discovered goof means you owe a test that reproduces it before (or with) the fix. |
Lazy TDD
From Dan Connolly's 2006 resolution: no more undocumented, untested code (MadMode, Mar 2006):
It's best to write the tests first … For personal projects, I'm not disciplined enough to write the tests first every time; if the code I write works the first time, I sometimes let myself get away with it. But I'm doing pretty well about doing test-driven debugging, at least. I write tests for any code that doesn't work the first time. And I write tests when I refactor and change things. The confidence to make changes that comes from having tests in place is very freeing.
the deal
- Got it right the first time? No test owed. Writing tests first is still best, but it's not required here. Don't pad a change with tests nobody asked for.
- Goof discovered? You owe a test. Any bug in code you wrote — found by you, the operator, CI, a reviewer, or a runtime failure — earns a regression test. No fix ships without it.
- Refactoring or changing behavior? Write tests covering what you're about to touch, so the change is made with confidence.
paying the debt (test-driven debugging)
- Write a test that reproduces the goof, in the project's existing test framework and style, next to related tests.
- Run it; watch it fail for the reason you expect. A test that passes before the fix proves nothing about the fix.
- Fix the code.
- Run it; watch it pass. Run the neighboring suite too.
- Commit the test with the fix (same commit, or test first).
Name the test for the behavior, not the bug ticket: "rejects negative amounts", not "fix for goof #3".
when a test is genuinely impractical
If the goof can't reasonably be captured in an automated test (e.g. it lives in config, a one-off script, or untestable I/O with no seam), say so explicitly, explain why, and suggest the seam that would make it testable (see no-ambient-authority for injecting I/O). Don't silently skip the debt.