Re: [boost] How to make tests building faster?

Subject: Re: [boost] How to make tests building faster?
From: Mateusz Łoskot (mateusz_at_[hidden])
Date: 2011-12-21 12:48:09

On 20 December 2011 19:22, Robert Ramey <ramey_at_[hidden]> wrote:
> Vicente J. Botet Escriba wrote:
>> Le 20/12/11 14:39, Mateusz Loskot a écrit :
>>> 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 started using Boost.Test and I abandoned it because Boost.Test was
>> broken on cygwin since I don't remember which version and the report
>> of individual tests doesn't appear in the regression tests. Of course
>> I would use it if Boost.Test is supported on this platform and the
>> regression test report takes care of individual tets.
>>> Â  Â (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.
>
> Here's an idea - TEST LESS.

Sounds familiar :)

> Here is what I do:
>
> a) on my local system I run my current version of the serialization
> library against the Boost Release Branch. Â I do this by changing
> the directory of the serialization on my local system to the trunk
> while leaving the rest of boost on my local system as the release
> branch. Â This effectively tests my next version of the serialization
> library against the "next" release. Â This has a bunch of advantages:

I'm interested in your practice here.
How do you do the "changing the directory of the serialization"?
Do you copy and overwrite, use symlinks?

> 1) I control when the other boost components change by updating
> the release branch on my local machine only occasionally - like
> before a check -in. Â So usually, not all of my tests have to be rebuilt.
> Normally it's only the one that's required to test the header I actually
> changed. Â If I make an improvement on one test, only that test get's rebuilt.

Sounds reasonable.

> 2) I'm testing against "known good" components - the next release branch.
> [...]
> Doing things this way lets one use boost test without overloading the
> boost test developer with the responsability to have is version in the
> trunk bug free and rock solid all the time - which is not what
> the trunk is for.

I have to admit, I have been too lazy to use branches/release that way.
Anyhow, this approach sounds very reasonable and I've got new bigger
hard drive now,
so no excuse.

> Try this out - it will help a lot.

I will. Thanks!

Your approach combined with John's suggestion to use PCH should be a
nice time saver.
Plus, I bjam jobs switch, even if I have only two cores.

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