>Listing out the tests you're going to write before you write the code (even mentally) can be considered a continuation of the requirements-gathering process.
But this is not TDD.
I've worked in HW industry where cost of bugs is high and we analyzed specs during brainstorming session as 3-5 ppl and brainstormed test cases that we want to test.
It worked well because this way we we're finding way more things to test than when doing it alone.
But still, this is not TDD. We weren't doing TDD.
>(Particularly, it seems to encourage the single-responsibility principle, as code that's doing too much or combining layers of abstraction is really hard to test.)
Whether your code is easily testable will be challenged by writing tests regardless of the moment of writing test - before or after writing impl.
But this is not TDD.
I've worked in HW industry where cost of bugs is high and we analyzed specs during brainstorming session as 3-5 ppl and brainstormed test cases that we want to test.
It worked well because this way we we're finding way more things to test than when doing it alone.
But still, this is not TDD. We weren't doing TDD.
>(Particularly, it seems to encourage the single-responsibility principle, as code that's doing too much or combining layers of abstraction is really hard to test.)
Whether your code is easily testable will be challenged by writing tests regardless of the moment of writing test - before or after writing impl.
So no benefit from TDD over non-TDD approach.