magpiebrain

In Artima’s “third part(Contract-Driven Development – A Conversation with Bertrand Meyer, Part III)”:http://www.artima.com/intv/contestP.html of their interview with Bertrand Meyer, some interesting comparisons regarding Design by contract and Test Driven Development are made. Bertrand Meyer makes the point that the small units of work that get undertaken in a TDD cycle (write the test, run the test, refactor) and very specific tasks that are nothing more than testing/implementing parts of a wider contract. When I use TDD, I do in fact tend to write at the top of my todo list the overall task I’m trying to achieve, which I’ve realised is the contract itself. I do not think there is much difference between the TDD and Contract-Driven approaches, certainly they try and achieve the same goal – which in Bertrad’s own words is to “build software in which reliability is built in rather than achieved after the fact through debugging”, or as Kent Beck would say (to paraphrase) “Ask the computer if it works, don’t try and work it out for yourself”.
The differences between the two are simply down to scope. The scope of a contract can be as small as a single test for a trivial example – or it can be as large as several. Both approaches still require that the larger problem be broken down and solved, and be proven to work. It seems perhaps that yet again we have another virtually identical solution for the same problem.