Boost logo

Boost :

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2004-02-12 12:44:23

> > Say a library now covers 100 test cases spread out among five test
> > programs. I'd like to see those five programs refactored into one
> > program, still covering the 100 test cases. Or even adding more test
> > cases. A single program would cut the overhead, including the human
> > overhead.

Sorry I missed the beginning of the thread: how would having one program

> There are at least three drawbacks to this approach:
> 1. "something is wrong" is all the information you get from
> a failing test. Esp. you'll likely see only one of several
> problems related to a failing test program. The next
> problem will only become visible after the first problem
> has been fixed.

This is not necessarily true. If one uses Boost Unit test framework you most
probably get all the errors in one shot.

> 2. Some tests are known to fail for certain compilers.
> If those tests are joined with other tests then we'll
> lose information about these other tests.

If it runtime errors you could rely on "expected errors" feature. You are
right for compile time errors, though one could try to ifdef part of test


Boost list run by bdawes at, gregod at, cpdaniel at, john at