He's railed before against rspec and now he's being vocal about automated developer testing in general.
Whilst its great to question the status quo, I hope this doesn't signal a return to untested code.
|Is the flock now going to consider testing as harmful?|
DHH's post, in my opinon is actually very good but it doesn't cover new ground. Its been observed for some time that :
- TDD is not about just 'catching bugs'.
- 100% Coverage is not pragmatic in 100% of cases.
- Code coverage is a metric that is fundamentally useless.
- Great swathes of tests are a maintenance headache.
- Writing testable code is a constraint on your design.
Now as time has progressed I find it more useful to write my expectations of what the stakeholders want. This means I think less about passing code and more about making features. TDD still has a place, a Behaviour Driven-style seems to fit better for me. Some of the BDD tooling I've used just was too much of an overhead in my situation, which is why our team dropped SpecFlow (a cucumber port) for MSpec (a cousin of RSpec). But we don't need to use any of those tools. It's entirely possible to do BDD with XUnit or anyother flavour of automated testing tools. It's just about OK to write tests after as long as you are clear what you are testing. (You wouldn't want to test the wrong thing.)
What the rise of TDD has given us though is a focus on quality, a return to craftsmanship. We don't want a return to shops thinking its ok to just sling code out and for their customers (or QA) to deal with the aftermath. There is of course a balance. I'm glad that people are beginning to question the practice. Over the last few weeks I've heard Dan North, Michael Feathers and now DHH push back but please don't stop testing.