[boost] How to make tests building faster?

Subject: [boost] How to make tests building faster?
From: Mateusz Łoskot (mateusz_at_[hidden])
Date: 2011-12-20 08:39:31

Hi,

I'm trying to figure out if there is anything I could do to improve
compile/link-time for tests of Boost.Geometry library.

Currently, the tests follow fairly canonical approach in Boost:

1) Each .cpp file defines a single test program and all local test
    routines are executed from test_main()

// test_feature_x.cpp
void test1() {} // make use of BOOST_CHECK_* macros
void test2() {}
int test_main(int, char* [])
{
    test1();
    test2();
    return 0;
}

2) Jamfile per testing project builds and runs each program separately

# features/Jamfile.v2
test-suite test-features
    :
    [ run test_feature_x.cpp ]
    [ run test_feature_y.cpp ]
    ;

3) Root mylib/test/Jamfile.v2 defines testing projects to build and run

import testing ;
project boost-mylib-test : ;
build-project features ;
build-project algorithms ;
build-project abc ;

In total, there are nearly 170 test programs in Boost.Geometry.
Obviously, running the whole set of tests (b2 command issued in
libs\geometry\test)
is time consuming process.

I'm wondering if there is any way to reorganise the tests to cut down
the build (linking) time.
My first idea is to decrease number of run entries (e.g. [ run
test_feature_y.cpp ] ) in Jamfiles,
by building related tests as single test suite program. Conceptually:

   [ run test_feature_x.cpp test_feature_y.cpp ]

Currently, there is no use of Boost.Test features for tests organisation like
BOOST_AUTO_TEST_CASE
BOOST_TEST_SUITE
etc.

I wonder if use of any of the above would help in restructuring tests and
decreasing number of programs to build.

Another aspect of Boost.Geometry tests I'd like to improve is to
improve tests report output.
Currently, it is reported as *Passed* or *Failed*.
I presume that using Boost.Test to group tests in suits with test
cases would improve
test report providing details about location of failure (which suite,
which case, or even better).

I'm looking for any piece of advice on the issues discussed above:
- How to cut down build time of tests?
- How to improve test output report
  (and keep it suitable for Boost regression testing framework)?
- Is it advised to switch to use Boost.Test features to manage suites
and test cases?
  (I tried to figure it out browsing tests of other libs, but it
doesn't indicate any preferred practice).

I'd be thankful for any insights.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net