In my experience, TDD adherents tend to work in languages with no type systems (JS, Ruby, Python) or languages with types of insufficient expressivity to enforce invariants in the code without significant effort (Java). Unit tests are ultimately failings of your type system, a sufficiently advanced type system with dependent types would make them entirely redundant IMO. Integration tests are still useful as a compiler can hardly be expected to check the validity of cross-application-boundary concerns (unless?).
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.
> 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.
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.
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.