TDD and BDD are security blankets for enterprises and clients. They add disproportionately little value, and significantly increase the cost of evolving an app in any direction.
TDD/BDD are just tools, in some cases they're useful and some other cases they're not.
If your work is deeply exploratory and you don't even know what the final interface/API will look like, you shouldn't start with TDD. You should probably test as you go though, once you find some behavior you'd like to keep and pin down variations and edge cases you met during dev.
If/Once you know what the expected behavior is, you can encapsulate that knowledge in tests, that's TDD to me. Then, I can write more code that meets the need of the expected API.
TDD and BDD teaching and tutorials are almost universally terrible so people inevitably do them badly and then moan about the results, which can be worse than not using them at all.
Usually the primary mistake is either using cucumber (which is awful) or surrounding the wrong interfaces with tests (usually at too low a level).
I've learned from the so-called experts for years. I studied directly under them. I spent so many years trying to find the perfect way to do TDD and BDD. I saw their own code and their own solutions up close. They're frauds. It was all a sham.
Perhaps. More than a famous guru I find most companies badly need a testing framework that can simulate 90% of possible scenarios hermetically and lack somebody who can build that.
Once you have that and somebody has taken you around the block 3 or 4 times pairing with TDD on your app it usually starts to make more sense.
On my team after I inculcated the TDD habit properly, BDD came naturally. I didnt even encourage them to have conversations with the PO while screensharing the tests. They dont even know that's called BDD.
People who think like that commenter implied, are almost always indoctrinated into "if you don't write tests and use TDD or at least BDD, you're literally Satan."
If your work is deeply exploratory and you don't even know what the final interface/API will look like, you shouldn't start with TDD. You should probably test as you go though, once you find some behavior you'd like to keep and pin down variations and edge cases you met during dev.
If/Once you know what the expected behavior is, you can encapsulate that knowledge in tests, that's TDD to me. Then, I can write more code that meets the need of the expected API.