TDD for the Lapsed
About 30 people showed up for an interesting discussion of
Test-Driven Development / Test-Driven Design
TDD generally says to write Tests First: the Red/Green/Refactor mantra.
Some of us do that for a while, then fall back to writing Tests After.
We mostly agreed that so long as the tests are written in the same session
and inform the design, it doesn't really matter. Others strongly preferred Test-First
Test-First gets you:
1. define problem
2. get feedback
3. regression testing
4. granularity
If you write the tests long after, you get #3 and #4, but not #1 and #2
If you write code first, then tests, say it takes 60 minutes to write the code
and X minutes to write the tests. Whereas, if you interleave, it takes X + 30 to do both
(or so it was asserted).
Test-First: Write Test, Write Code, Design.
Design-First: Design, Write Code, Write Test => never Red
Thinking about tests drives clarity of code.
Hint: use nouns, not pronouns, to describe behavior.
TDD is great for pure, side-effect-free code.
Not so good for when you don't know what to do.
In that case, spike to explore problem, then TDD for code + tests.
Use mocks for behavior: makes tests easier and more robust
Mocks for implementation => harder, more brittle
