[torben-friis]

Sometimes you need the unit before you can unit test.

So you end up writing the unit's boilerplate, that doesn't yet do anything but needs to compile/run for a suite to test it throwing a adhoc error of the notImplemented sort or whatever, then break flow to set the test suite and check the reds (that aren't telling you anything useful because of course it's red), then actually write the code.

I find it flow-breaking and cumbersome for little to no gain.

For additions to existing code I find TDD more useful, but even then it's not unusual to decide to move logic around until deciding a final structure, so the units you end up with might be solidified later in time. Writing tests for scraped units is a waste of time then.

[hitchstory]

>Sometimes you need the unit before you can unit test.

Right. In those situations I TDD with an e2e or integration test.

I dont get why youd restrict yourself to doing TDD with just with low level unit tests.

[torben-friis]

I don't, but you agree that in that case the unit test comes after? That was the point I was arguing.

[hitchstory]

Not necessarily. On plenty of projects I have done 100% TDD and never written a single low level unit test.

The type of test is, in my mind, a completely different topic to red-green-refactor and for the decision about which one to write I follow a set of rules which is also unconnected.

TDD is just red-green-refactor. It works with any test.