From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-19 19:37:07
At 10:59 PM +0200 4/19/01, Ullrich Koethe wrote:
>Jesse Jones wrote:
>> I've uploaded a new version of the DbC files.
>I've followed the discussion with great interest. Since I've been
>working (with Beman) on an improved unit test facility, it occured to me
>that it might be a good idea to integrate unit testing and Design by
>Contract. This would have at least two advantages:
>1. Avoidance of code duplication - many things in the unit test
>framework are similar to what you are trying to achieve.
For the most part I think unit tests and DbC are complementary
concepts. In my experience unit tests are also more useful than full
>2. Simplification of DbC: From the discussion so far I got the
>impression that especially invariant testing imposes some problems in
>C++. Thus, it might be a useful policy, to check invariants primarily in
>test programs, and not in production code. This would solve two
> - costly invariant checks do no harm in test programs
> - it is easy to solve the accessibility issue by declaring the
> tester class a friend of the class being tested.
Invariant checking isn't that hard to do. It's just a matter of
finding the right tradeoffs. I also think most people would be
willing to accept a significant speed hit in debug. What is useful is
if the unit tests can enable extra debugging checks. For example, I
have a gIntenseDebugging flag (stolen from MacApp). When this is
enabled I'll do non-constant time checks in my invariants. My unit
test code enables gIntenseDebugging and restores it before it returns.
>Please take a look at the proposed unit test code at
>Any opinions will be appreciated.
I need to look at this more closely, but I have some initial impressions:
1) I prefer to integrate unit testing into my app. This makes it
easier to run the tests and means that the tests use the same compile
and optimization settings as my app. It'd also be nice if I could
stick the test names in a menu and run that test when the menu is
2) If you do support app integration there needs to be a way to turn
off the tests. Relying on NDEBUG may not be adequate because the
professionally paranoid will want to run their tests in something as
close as possible to the release build.
3) The code uses iostreams in the header. This gives me the screaming
willies. I used to have template member functions in an XML attribute
class that used iostreams to get the data in and out and it was
causing insane amount of bloat. Of course the linker stripped most of
it out, but I'd rather not worry about enormous object files if I can
help it. Most of those routines should be outlined anyway...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk