September 19, 2006

...Learn TDD with Codemanship

Worth Building? Worth testing!

One of the brutal - but entirely necessary - consequences of test-driven development is that if there's no test for it, it ain't gonna happen. It's vital that customers understand that if they want something from the software - be it a feature or be it something non-functional like performance or scalability - they must agree a test for it, or the developers won't deliver it.

Less progressive-thinking people have some difficulties with this. Too many project teams fall into the "but it's common sense, surely" trap of being expected to fill in the implied gaps in the specification. This allows the customer to spend as little time as possible helping to pin down the spec. This is, of course, time saved that will be wasted twice over a few months later when there's all those change requests and bug reports to write...

Even the simplest coding tasks cost a lot of money. And it's not our money. The decision as to precisely what gets developed should lie squarely with the customer. And the Devil is in the detail. That's why I insist on agreeing tests before I'll write a line of code.

But it's hard work, don't you know. Back in the good old days customers could just wave their arms about and say stuff like "it has to be easy to use and infinitely scalable" and we were expected to go away and build for them in 6 weeks with a team of about 3 million programmers. (Based, no doubt, on the old "infinite monkeys" theory of productivity).

Now we have the nerve to expect them to waste time writing acceptance tests? But if it's worth building - which is an expensive business - then surely it's also worth testing? Isn't any software that's worth writing therefore worth agreeing tests for?
Posted 14 years, 8 months ago on September 19, 2006