Earlier quoted context omitted.
I don't use the proscribed TDD process very often, but I use the TDD mindset all the time to great effect. 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. And thinking about how you're going to test your code before you write it will, in my experience, improve the design. (Particularly, it seems to encourage…
>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 t…
That's true. Did you miss the part where I mentioned the "TDD process" versus the "TDD mindset"?
> Whether your code is easily testable will be challenged by writing tests regardless of the moment of writing test - before or after writing impl.
I don't want to derail the conversation, but when I'm working on projects alone then my test coverage is 100%. (Line and branch coverage.) But surely that slows me down, right? And I must have a million test cases? No, quite the opposite actually. Writing code that way is just a skill though, the same as juggling, that becomes easy with enough practice. (Along with the right practices and tools.) However, I don't aim for 100% (or even a particularly high percentage, to be honest) when I'm working on projects with other people, because the only way it's possible is if the code was designed for it from the get-go.
I encourage junior developers to learn and try to use TDD for a while because it can be useful sometimes and improve the way they write code. But I would never require them to do it.