Re: [boost] [contract] Contract Programming Library

Subject: Re: [boost] [contract] Contract Programming Library
From: Jason Felice (jason.m.felice_at_[hidden])
Date: 2010-01-06 09:04:58

On Wed, Jan 6, 2010 at 7:19 AM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
> Hi Thomas,
>
> On Tue, Jan 5, 2010 at 12:56 PM, Thomas Klimpel
> <Thomas.Klimpel_at_[hidden]> wrote:
>> How about my interest in such a DbC library, and would I use it? I would be interested to see how DbC can be done in C++, and how it will feel. On the other hand, I "know" that I will not use DbC for "real" projects, even so I completely acknowledge the benefits it has with respect to documentation and testing. This is because testing is too important to focus on a single "random" aspect. The test requirements of different projects are so different that in principle testing should start with an investigation of the test requirements of the individual project. I fear that DbC would give a false sense of security with respect to testing. I have less problems with the documentation part of DbC, especially since it avoids the "obsolete" problem that typically plagues documentation.
>
> Indeed, [Ottosen2004] expresses a similar concern. I will add the
> "false sense of security" concern to the library documentation in the
> Contract Programming annex.
>
> Personally, I have used Contract Programming in a couple of real
> projects -- one of which, an embedded safety critical system with
> ~60,000 lines of C++.

In case others are curious, here's how I would use it in a "real
project":  I currently use test-driven development.  The standard
xUnit format for tests has quite often become horribly cumbersome and
I even blogged a bit about why and my solution here:

http://eraserhead.net/2009/12/write-a-test-driver-class/

My test driver classes serve two primary functions:
1. To build and inject all the dependencies so I don't up with
spaghetti code, large setUp() and tearDown(), and lots of free
functions in my xUnit suite class.
2. To enforce class invariants and post-conditions.

(My test driver class delegates to the class under test.)

It's a bit of work, and sometimes the driver class gets heavy and is
difficult to understand.

I use the tests as executable documentation to begin with, so if I can
push "executable documentation" of pre-conditions, post-conditions,
and class invariants back into the class under test, I think this
would much improve readability of both the class itself and the
testing code.

So it's really something I'm already doing by having significant test
coverage, but that this would improve on.