Fog Creek Software
Discussion Board




Design By Contract

I felt bad because my last few posts were a little off topic.  I thought perhaps starting a discussion about Design By Contract (DBC) might simultaneously satisfy my apparent need to talk about contracts and stay on topic.

Just wondering why I don't hear more about the use of DBC from the XP proponents out there?  Is it being used, but not often mentioned?  Are most folks doing XP-style development unfamiliar with it?  Has it been tried and failed to live up to its promise?  Is it simply "too formal" for XP?

As I understand it, one of XP's basic tenets is "Test first; test often."  I've frequently heard it recommended that writing unit tests and then running them periodically is the correct way of doing this.  It seems to me that DBC would be a powerful tool for designing, implementing, and facilitating the required unit tests.

Unit tests seem to have two important pieces.  The first part is the data pump.  Its responsibility is to hammer a module's interface with well-chosen test data.  The second component is responsible for checking the integrity of the module being tested in response to the actions of the data pump. 

I think DBC would shine in the role of this second component.  Here are a few reasons:
*  It has a proven history and a sound theory behind it.
*  It binds the semantics of the test directly into the module. 
*  Environments that support it can cause the tests to be run while the module is executing in a fully integrated system.
*  The theory automatically incorporates consistency constraints arising from object oriented type systems.

This is very potent stuff.  Is anyone integrating it into an XP-style development effort?  Does anyone have any results or experience to share?

Keep_Your_Rules_To_Yourself
Friday, June 21, 2002

An xP person would probably say that anything beyond unit tests + assert offers diminishing returns, since DBC is rarely supported by the language.

There are 3rd party tools, but some require a preprocessor, and others may be closed-source.  I suppose this is why people go with extensible languages.

jon s.
Sunday, June 23, 2002

I have never used design by contract but I have used unit testing/xp and I thought I would share a link I dug up:

http://c2.com/cgi/wiki?UnitTestsDefined

There are many other mentions of DBC on that wiki, and it seems that most xp advocates see it as a compliment to unit testing.

Ian Stallings
Monday, June 24, 2002

My view is that DBC complements (that word again!) XP's testing-oriented approach perfectly. I'm (supposed to be) writing an implementation at the moment, and I'm doing a lot of stuff using a DBC framework in C#. Eg

public void AddToList(Thing thisThing)
{
  DBC.require (mList.Find(thisThing) == false);
  mList.Add(thisThing);
  DBC.ensure (mList.Find(thisThing) == true);
}

This isn't really 'by contract', since the contract is being met by code rather than some form of declarative approach like the Eiffel mob have. but better than nothing.

I'm lookink forward to wish John Lam ( http://www.IUnknown.com ) doing something more with his CLR implementation of aspects, so I could do

[Attribute DBC.require (thisThing != null)];
[Attribute DBC.require (mList.Find(thisThing) == false)];
[Attribute DBC.ensure (mList.Find(thisThing) == true)];
public void AddToList(Thing thisThing)
{
  mList.Add(thisThing);
}

If thats not ruthless testing, I don't know what is!

Mark Smith, http://www.virtualmethods.com
Monday, June 24, 2002

*  Recent Topics

*  Fog Creek Home