- Write the scaffolding test to call the new "thing"
- Add basic assert to check your thing was called with right input
- Add more logic to "thing"
- Incrementally add more asserts to check for output, side-effects etc.
- Write the scaffolding test to call the new "thing"
- Add basic assert to check your thing was called with right input
- Add more logic to "thing"
- Incrementally add more asserts to check for output, side-effects etc.
The only time I write more actual tests is when squashing bugs.
In my steps above, i was switching the order in between 3 and 4. Adding logic to "thing" first and then updating the test to match; mocking and patching my way across. So implementation first and tests later. Lazy TDD as another commenter mentioned.
It's well worth reading, very short (and pretty funny also).
But yeah, the approach he suggests is to write the minimal failing test, then make it pass, then repeat. Red, green, refactor is the short form of his approach.
But your misconception appears to be incredibly common, I've heard it from so many people over the years. No idea where it came from, but it's nonsense (IMO, obviously).