Sponsored Link •
Bertrand Meyer talks with Bill Venners about how Design by Contract relates to test-driven development.
Bertrand Meyer is a software pioneer whose activities have spanned both the academic and business worlds. He is currently the Chair of Software Engineering at ETH, the Swiss Institute of Technology. He is the author of numerous papers and many books, including the classic Object-Oriented Software Construction (Prentice Hall, 1994, 2000). In 1985, he founded Interactive Software Engineering, Inc., now called Eiffel Software, Inc., a company which offers Eiffel-based software tools, training, and consulting.
On September 28, 2003, Bill Venners conducted a phone interview with Bertrand Meyer. In this interview, which is being published in multiple installments on Artima.com, Meyer gives insights into many software-related topics, including quality, complexity, design by contract, and test-driven development.
Bill Venners: When I was reading your book, Object-Oriented Software Construction in preparation for this interview, I found that many of the claims you made about Design by Contract reminded me of claims made about test-driven development. You wrote that Design by Contract "helps us build software in which reliability is built in rather than achieved after the fact through debugging." You also wrote, "We will derive tremendous benefits from writing the assertions at the same time as we write the software, or indeed before we write the software." And, "With hardly any extra effort, you get software that works the first time around." How does Design by Contract achieve this, and how is Design by Contract the same or different from test-driven development?
Bertrand Meyer: A test checks one case. A contract describes the abstract specification for all cases. Test-driven development is an interesting idea, but I think the way to go is to derive the tests from the contracts.
I think there are two kinds of people interested in test-driven development. First, there are people who are very happy not to have to write a specification. If that's what you hope to get from Extreme Programming (XP), I don't think you'll get much improvement. But then there are people who are more seriously applying the idea of test-driven development, the way at least I would consider applying it, where the tests are really systematic. 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.
Bill Venners: What do you mean by systematic?
Bertrand Meyer: It was shown many years ago through a very simple argument that there's no such thing as an exhaustive test, a test that exercises all possible cases. So we know we can't have an exhaustive test, but we can have systematic tests that have a likelihood of exercising the cases that will fail. For example, if you have a parameter that must be between certain bounds, then you want to test the values close to bounds of the range. You want to test maybe the value in the middle, and maybe a few in-between. So we want to have tests that are systematic in that sense, and contracts help a lot generating such "systematic" tests.