[sidmitra]

This also can be articulated as a sort of incremental TDD.

- 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.

[sneak]

I do this but skip the last step, I call it ultra-lazy TDD. It's really just a toolchain/syntax/library import check.

The only time I write more actual tests is when squashing bugs.

[disgruntledphd2]

This is classic TDD, right? Certainly this is the approach taken by Beck in his book.

[sidmitra]

I must confess, i never read the original book/paper, just about it from various sources. I was under the impression that in "proper" TDD you always try and write the test first; so as not to taint your tests with un-necessary implementation details

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.

[disgruntledphd2]

> I must confess, i never read the original book/paper, just about it from various sources. I was under the impression that in "proper" TDD you always try and write the test first; so as not to taint your tests with un-necessary implementation details

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).