Sometimes people manage it in which case it resembles a mini superpower but mostly they do not.
If it mirrors the spec then few people would change it to be wrong to make the test work.
I have only seen TDD used poorly, as a crutch, an alternative to thinking deeply about the problem space. If it can be done well I have not personally seen it. Perhaps SQLite, but such projects are an oddity.
To me tests at the spec level are largely user acceptance tests which are indeed very useful.
>I have only seen TDD used poorly, as a crutch, an alternative to thinking deeply about the problem space. If it can be done well I have not personally seen it. Perhaps SQLite, but such projects are an oddity.
Theyre not that odd. I've applied it to every type of code base I've come across.
>To me tests at the spec level are largely user acceptance tests which are indeed very useful.
Where I use TDD the tests are exactly like this - written at the highest level possible using a shared framework that integrates sophisticated fakes which carefully balance realism, speed and flakiness. They all follow roughly the same pattern across the code base and that pattern mirrors the spec scenarios.
Where I see TDD used by people who complain about it they usually think the idea is to write a test for a class because they're thinking about writing a class. It is generally taught badly.
That's it. It says nothing about the type of test you write. Personally i do it with literally every type of test that i write - acceptance, integration, unit.
If you write a decent test, yes, TDD is always valuable. If you TDD with shitty tests, not so much, but that isnt really an issue with TDD.
