See that skinny white line up there in the stratosphere? That’s the point, or one of them, whooshing over your head.
Perhaps your eyes moved over what I wrote but there is no evidence in your response that it made any cognitive impression, so as far as I’m concerned, no, you didn’t read it.
Because if you think that writing tests prior to coding saves time, you absolutely did not read what I wrote. The point isn’t a subtle one, it’s blatant: we learn things while coding we didn’t think of while designing, so writing tests to a half-assed design means either writing shoddy tests or revisiting them over and over. It’s fundamentally and intrinsically inefficient. TDD is stupid.
Two, if you think a developer should have primary responsibility for testing his work then you are either a very junior developer or you have never written code at all. Since most people who’ve responded to my many articles on this seemed to understand and agree, I’m not going to explain this again save to ask you to seek out the phrase “blind spots” and read with more care than you’ve exhibited thus far.
Refactoring, technical debt, “stories” … bullshit nomenclature for old ideas. Breaking complex projects down into manageable components didn’t begin with that “agile” fad and and it didn’t begin with that “scrum” fad; it predates assemblers.
I don’t write unit tests. They’re too much work and they add too little value. They also involve making design compromises e.g. making private functions public, which I won’t do.
Tests should be written to verify compliance with a functional specification and written by someone else, without knowledge of the code. We call it blackbox testing. Unit testing is an inferior version of what we call whitebox testing, which is usually written by the developer as a preliminary test so he doesn’t waste the real testers’ time.