I have just come onto a project that has tests up to the armpits, mocked everything, and the test lead wielding an almost evangelical bent across the developers. And the codebase and system is still shit.
Why? Because the team though loads of tdd and bdd equals a great system.
Wrong.
They can help, when used sparingly, but to make them your design methodology, praying at the church of testing dogma is insane.
So, no tests bad. Worse, over testing. When I see fourteen tests to one code unit, I know now to run away.
TDD is just really efficient at demonstrating your inadequacy at achieving this goal. It's a really uncomfortable experience, and to get comfortable with that feeling takes a certain acceptance of the human condition that reads like something straight out of eastern philosophy.
Tl;dr to err is human. To really fuck up requires the aid of a machine.
A good point. I think the bigger learning exercise for this team in particular would be: do we need this test and why? To make them examine a bit more about what they are trying to achieve and not just succumb to testing by numbers.
Ultimately, the large battery of tests passes, but when the system is still borked, the disconnect is great.
Many businesses want to treat developers as a fungible commodity and believe some magical process will enable that. It makes sense financially but I've never seen it actually work.
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.
