Re: Over testing

It seems that one of the questions I asked on StackOverflow has gained some attention today, @dhh (of Ruby-on-Rails and 37Signals fame) mentioned it in a post on "over testing".

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.

Before I got into writing automated tests I used to write a pseudo code comment, then write the code, then remove the comment. Then unit testing came a long and I began to automate that psuedo-code. Of course things take longer this way. Not only do you have to solve the difficult problem but you also have solve the difficult "getting things under test" problem. But here's where the power lies: By writing your intentions down you are forcing yourself to consider what you are doing. Its an extra step. Yeah there will be some rock star, alcohol drinking brogrammer who can write that code a billion times better than you without tests but even ninjas make mistakes sometimes. So I prefer to set up a test up front.

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.