On Wed, Jan 6, 2010 at 7:19 AM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
Hi Thomas,
On Tue, Jan 5, 2010 at 12:56 PM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> 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.