In this “interview with Bertrand Meyer”:http://www.artima.com/intv/contest.html on Artima, Bertrand Meyer hopes that Test-Driven Development is like Design By Contract. Well, yes and no.
Meyer has the good grace to admit he hasn’t really had time to look into TDD, but his view is that:
bq. I haven’t had the opportunity to talk to, for example, Kent Beck about this, but I hope he would agree that the right form of test-driven development is where the tests are systematic. And the best way I know to derive a systematic test is from contracts, because they’re much more general and abstract. You can derive the specific from the general. You cannot really infer the general from the specific.
First, he has the usual misunderstanding of TDD being about testing, not unreasonable given its name. But “extracting the general from the specific” is exactly what the refactoring part of TDD does, that’s how you remove duplication. The flip from Design as a Process of Invention, to Design as a Process of Discovery takes a little while to get used to but it’s liberating. It puts an end to the “deer in the headlights” experience where there are just too many unknowns to make the next (binding) decision so you find yourself incapable of deciding anything.
There’s another, more interesting, discussion that I think is worth having with the Design By Contract community. One of the important experiences of TDD is that you can control the scope of the code by adding and removing individual tests. You can slice and dice functionality and it’s easy to understand. Contract specifications tend to be harder to manipulate that way because they describe general properties — that’s the whole point. I have a suspicion that this is just a matter of style, but it’s not how DbC people see things. Like Prof Meyer, I haven’t had these discussions with the right people either (so that makes us even?), but it would be entertaining to find out.