Boost logo

Boost :

Subject: [boost] [test] broken (fails to compile) with boost.timer since 1.48
From: Jamie Allsop (ja11sop_at_[hidden])
Date: 2013-10-10 11:53:48

Boost.Test fails to compile since 1.48 when Boost.Timer is included. I
find that often I want to use timers when testing. I reported this back
in 2012 along with a comprehensive patch that fixes the issue. On the
eve of 1.55 I see the patch has still not been applied, despite an
original agreement to do so. Unfortunately I don't have commit
privileges so I am unable to do this myself.

The original discussion from here:

went as follows:

> On 25/09/12 18:14, Gennadiy Rozental wrote:
>> Jamie Allsop<ja11sop<at>> writes:
>>> These are patches we've been using for some time locally, the recent
>>> discussions highlighted the importance of pushing patches like these to
>>> a wider audience.
>>> In summary the key changes are:
>>> *
>>> *
>> These are fine. I'll try to check it in on a weekend
> Excellent thanks!

Yet was never applied. With
changes to Boost.Test since then it is likely that the patch needs
modified to be applied but that should not be too hard.

Apart from that I'd like to see the suite of 4 patches applied as a
whole. So far only has been
applied but the patches address severe use-case short-comings in
Boost.Test that make it viable for broader testing use. I've summaried
them below.

    * (applied)
    * (small)
    * (small)

Original discussion that didn't really get very far was in these threads:

For those who are interested I've pasted my original motivations from
the year old thread below as a reminder. Basically the patches allow
Boost.Test to:
   * compile with Boost.Timer (so not broken)
   * output test progress on the fly in a format other tools could parse
   * allows Boost.Test to be used for live test diagnostics in running
systems in a 'test' mode


    * (applied)
    * all test cases/suites have file and line information captured so
that external tools can use the Boost.Log output to create links into
the source tree, answering questions like, "What is this test case?". It
is possible to simply follow the link and see.

    * update the Boost.Test log output to include summary status
information when a test case or suite is completed. This includes the
test status, assertions passed and total assertions. This allows live
test status to be viewed and nicer tools to be built around this. For
example each test can be shown starting, in progress and then complete
with the resulting status in detail. I should note that Boost.Test
reports currently output this additional test status but this is done
only on *completion of all tests* and so *cannot* be used to show live

    * this additional test status as part of the log can be easily
captured using regular expressions if HRF is used and many IDEs will
allow colourisation, autolinking and so on using similar approaches.

    * update Boost.Test to use the new Boost.Timer classes introduced in
Boost 1.48. This can be suppressed through the use of a macro should the
old timers be preferred. The new Boost.Timer provides much better timing
information than the old Boost.Timer library. You should refer to the
library itself for an explanation of why the previous timer library was

     Essentially the patch does two things:
    * It allows boost::unit_test_framework::init() to be called more than
once. The result is to reset the test status and master test suite so
that new tests can be added and new reports generated through multiple
calls. The CLA parsing is also reset. Recent changes to this code may
make my call to clear() redundant. I'll let Gennadiy be the judge of that.
    * This first change then allows the framework setup and teardown to
be encapsulated in a helper class (not provided in the patch but one
could be). In our systems we use a helper class that exposes a simple
API that allows the user to implement a method where test units can be
added directly to the master test suite - see the ticket for an example.
As I said the patch focuses solely on enabling the possibility of
writing such a class, not the class itself.
    * It provides scoped Boost.Test arguments for the commandline when
line arguments are then called --boost.test.<argument> for example
--boost.test.log_level instead of --log_level. This of course means that
all Boost.Test related arguments will not clash with any program
arguments. On its own this is a generally useful feature as it allows
custom main() functions to pass arguments down to other components
during simple unit testing.

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