3 ms·

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

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.

iamflimflam1 11y ago
Sadly you can't fix bad developers with process.
- jahnu 11y ago
  Nicely said. 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.
hinkley 11y ago
The real limitation in any system is this: Can you make the code say what you mean? 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.
- tddfuckwitz 11y ago
  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.
rogerbraun 11y ago
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.
- collyw 11y ago
  I hear this argument a lot for TDD, but most of the bugs I I get are from subtle ways in which data enters the system in a way that is unexpected.
6Anonymous6 11y ago
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.

iamflimflam1 11y ago

Sadly you can't fix bad developers with process.

jahnu 11y ago
Nicely said. 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.

hinkley 11y ago

The real limitation in any system is this: Can you make the code say what you mean? 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.

tddfuckwitz 11y ago
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.

rogerbraun 11y ago

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.

collyw 11y ago
I hear this argument a lot for TDD, but most of the bugs I I get are from subtle ways in which data enters the system in a way that is unexpected.

6Anonymous6 11y ago

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.