Dave Astels on Test-Driven Development (TDD)
Posted on April 27, 2006
Filed Under /dev/null/ | 328 views |
Apparently “The state of Test Driven Development” by Dave Astels is currently generating bug buzz on the web, and rightly so, it’s an excellent article on one way to approach test-driven development. I particularly like this paragraph:
It’s about figuring out what you are trying to do before you run off half-cocked to try to do it. You write a specification that nails down a small aspect of behaviour in a concise, unambiguous, and executable form. It’s that simple. Does that mean you write tests? No. It means you write specifications of what your code will have to do. It means you specify the behaviour of your code ahead of time. But not far ahead of time. In fact, just before you write the code is best because that’s when you have as much information at hand as you will up to that point. Like well done TDD, you work in tiny increments… specifying one small aspect of behaviour at a time, then implementing it.
And that’s it exactly: prove the parameters of what you’re going to build before you build it. Not just know them, the paper spec I’m developing from is how I know them, but create proofs for them and then force what I’m going to build to conform to those proofs. (Where I use “proofs” I expect Dave would probably call them something like “expectations”).
However I do disagree with Dave on this point:
When you realize that it’s all about specifying behaviour and not writing tests, your point of view shifts. Suddenly the idea of having a Test class for each of your production classes is rediculously limiting. And the thought of testing each of your methods with its own test method (in a 1-1 relationship) will have you rolling on the floor laughing.
I think this is still important in that code is all about the building blocks; everything is made up of smaller and smaller pieces, each of which can fail. As a developer I have to rely on my tools to be right in what they do (though as Linux, Linus and the gcc recently found out, this is not always true) to I don’t write unit tests for the basic functions provided by my programming language. Or rather, perhaps I can think of the code I write as tests for those functions.
But I do want to be able to prove to myself that each function I write does what I think it’ll do. And then I want to prove to myself that it’ll all behave the way it should when linked together. And here we re-join Dave’s train of thought:
Using a behaviour-centric framework that uses behaviour-centric vocabulary and concepts will let you think in terms of specifying the behaviour you want from you code.
It’s a subtle distinction from the way unit testing is currently thought of but probably an important one. And certainly one that fits nicely on top of the way unit testing is currently done. Where Dave’s article seems to be advocating a new way of testing I see an additional way - layer 2, if you will.
(Via The Farm )