That said, I think TDD is a cargo cult. I think a better approach is to determine on a case-by-case basis if a test is useful for whatever you're working on and developing a sense for that is part of becoming a better software developer. Things like coverage metrics completely obliterate this nuance and lead to some of the most obvious, ridiculous tests I've ever seen.
Do you have any hard evidence that this is actually a skill that some people have and others don't? How do you even measure it to verify?
I'm genuinely curious -- I've been thinking in these terms myself recently, too, but my literature search came up empty.
Not all unit tests are bad of course, but many in my context, imo, are unhelpful.
I'm often test-driving stuff with unit level tests and the only times I have to mock collaborators are when the collaborators are
- third party services,
- badly designed, or
- not built yet.
This has nothing to do with unit/integration level testing.
With integration tests my expectation is that we're using real dependencies just fake data which is often easier to set up.
We need to go back to writing code like we are on resource constrained systems, which forced you to be explicit in what you did and think about why you were doing it.
Then there is the code quality issue. The stuff that was written 20 years ago was somewhat hard to refactor because noone dared because who knows what would break. So basically every code base would degrade into a mess and become harder and harder to maintain over time. A code base that is maintained with automated tests can be improved as time goes on with relatively low risk.
perhaps the pertinent take-away is "be sure you test thoroughly" rather than "do things my way and you will mess your code up egregiously, likely increasing the cognitive load to work with it beyond sensibility, and maybe test thoroughly as a side-effect thereof".