dckc
7d593a13e4
Code that works the first time may ship untested; a discovered goof owes a regression test. Cites Dan Connolly's MadMode entry of 18 Mar 2006 on test-driven debugging. Generated-by: Claude Opus 5.5
51 lines
2.4 KiB
Markdown
51 lines
2.4 KiB
Markdown
---
|
|
name: lazy-tdd
|
|
description: 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](https://www.madmode.com/2006/advogato_entry0044.html)
|
|
(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
|
|
|
|
1. **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.
|
|
2. **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.
|
|
3. **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)
|
|
|
|
1. Write a test that reproduces the goof, in the project's existing test
|
|
framework and style, next to related tests.
|
|
2. Run it; **watch it fail** for the reason you expect. A test that
|
|
passes before the fix proves nothing about the fix.
|
|
3. Fix the code.
|
|
4. Run it; watch it pass. Run the neighboring suite too.
|
|
5. 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 [ocap-discipline](../ocap-discipline/SKILL.md) for
|
|
injecting I/O). Don't silently skip the debt.
|