The Failures of “Intro to TDD”

At least you can be sure that it does what you expect. You can have bad architecture with and without tests, but testing will help you to avoid surprising behaviour, regressions, that kind of stuff.

Yes, I've witnessed a over emphasis on TDD and BDD lead to a team regressing. TDD/BDD became the deliverable not the product.

This is even more prevalent in the test masturbation known as Cucumber. Like your experience the lead in this case a weak developer was extremely pleased we had a very high coverage using Cucumber and because we where using Cucumber, by proxy we where doing BDD right??? ;) So bonus points are to be gained when reporting to management. The fact was the Cucumber sweet was a heavy set of UI tests against the most fragile part of the system; what changes most in a html app? A: The UI. The implementation in Cucumber is poorly executed leading to hours debugging because of it's shared mutable state in Cucumbers global world giving absolutely no value as features under test could be tested lower down the stack more reliably, faster, giving more value. I'd go as far to say the only person getting benefit from Cucumber is the person reporting to management trying to look like they've been busy and proactive or someone selling their consultancy fee. Cucumber is nothing more than the work of Satan seeing how much punishment a team can take while chasing the mythical utopia promised but never quite reached! Better tools exist!!!

I'm not saying TDD/BDD is bad, I use it when I think needed and enjoy it when used sparingly when requeied. Doing tdd because someone told you so and then the tests taking higher priority than deliverable code is bad unless your code results in death or other hardship upon someone, in these cases you're best of using a more formal approach to testing! Cargo culting at it's best.

Methodologies aren't a substitute for creativity or intelligence.

At best they can give a person with good judgement a different angle to look at their problems with.

At worst they are thought-stopping slogans that turn a gullible novice into a crippled novice.

I wish I had time to write a decent post. Lacking time, I'll try to be concise. If you want to really understand the benefits of TDD, the best book I know on the subject is actually Michael Feathers, "Working Effectively with Legacy Code". It is rather dense and getting a bit dated, but by showing you what you need to do to improve legacy code in a methodical fashion, he provides the basis for learning how to do good TDD.

Here here to this. I never continue to be surprised by the number of people who don't realize that engineering is the practice of breaking big and confusing things into small things you understand.