Re: [boost] Re: Boost.Assertion

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-19 19:37:07

At 10:59 PM +0200 4/19/01, Ullrich Koethe wrote:
>Hi!
>
>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 
blown DbC.

>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
>problems:
>
>   - 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
>
>http://groups.yahoo.com/group/boost/files/unittest/
>
>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 
selected.

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...

   -- Jesse