This is the typical post that I find when people try to do TDD but without learning it properly, and also, I have to say it, without any intention of doing it well and full of biases.

Probably, TDD is one of the bests techniques ever invented to develop code and to make the life easier for developers. Yet, decades of bad practices and bad uses of testing make it hard to fully realize and take advantage of all its potential. Even in some of those cases, they do a kind of testing that goes completely against the TDD requirements and that is actually harmful to the code, as the author describes, or even as much earlier David Heinemeier Hansson wrongly said, with just a few weeks of experience. I don't know how many times people have asked this stupid question to me (completely irrelevant for TDD and a telltale that you got it wrong): do you test the public methods or also the private ones? That's nonsense!

Normally, in such cases, I would recommend learning it from the sources: Robert C. Martin, Kent Beck, Ward Cunningham, ... But there are many more later that are also quite good, like Dave Farley or Dan North. In the case of Robert C. Martin, he has excellent paid videos.

But I know that years of bad practices, preconceptions about the futility of testing, and consequently, repeated bad results, give the idea that as technique is useless.

Well, no so far fetch because, according to its creator, TDD is really a stupid idea. But not because it is useless, but because it goes against all our instincts and our learnings. And, of course, that is the same exact reason what makes it so hard to understand and practice.

So, in those cases, is when I say: TDD is not for you.

Stop practicing it. Period. It is the best thing that you can do for the TDD reputation.

But, just but, if you want to try, just think of the following trick: write your tests as they were the documentation. The documentation is decoupled from the code, it explains what the application does, and it teaches how it does that.