Re: [boost] What Should we do About Boost.Test?

Subject: Re: [boost] What Should we do About Boost.Test?
From: Bronek Kozicki (brok_at_[hidden])
Date: 2012-10-02 05:14:04

On 28/09/2012 07:30, Roland Bock wrote:
> On 2012-09-17 16:40, Dave Abrahams wrote:
>> Hi
>> As a straw man, I'll make this suggestion:
>>
>> - Boost.Test is officially deprecated in the next release
>> - Its documentation, such as it is, is removed from the release after
>>    that
>> - Meanwhile, other tests in Boost that use this library are rewritten to
>>    use a different mechanism
>> - The code is removed from Boost thereafter
>>
> First of all: We are happy users of Boost.Test!
>
> I haven't counted the number of test cases we handle with Boost.Test in
> my team, but unless
>
>    * there is a replacement
>    * there is tool support for migrating
>
> we would be stuck with the latest version of Boost that offers Boost.Test.

+1.

We are currently using Boost.Test for large project and don't plan 
migrating to anything else. I don't see any major problems with 
Boost.Test. Futhermore, for simple test cases that we have, its 
documentation is sufficient. There are few test frameworks with good 
community support and widespread use, however since many of those are 
too intrusive there really aren't that many alternatives to Boost.Test, 
for us.

Of course Boost.Test could be improved. e.g. I would not object to being 
able to write a unit test, with a proper execution monitor, which does 
not need to link to anything. Perhaps it's just a question of 
documenting better what Boost.Test already does.

If an alternative was provided in some future version of Boost, with 
nearly-compatible interface (i.e. one which would work with our existing 
test fixtures and checks), we could consider switch. Without such 
alternative, we will be stuck on the last version of boost where 
Boost.Test is available. Simple as that.

Also I'd like to raise another point: I rarely follow Boost discussion 
so am not aware how many times it's been suggested that some library be 
dropped from boost, but unless such a library is "for internal use 
only", it would be clearly breaking change which should not be proposed 
lightly. Boost.Test is not "for internal use only" and removing it would 
break Boost for many of its users. If Boost was modular library with 
users able to pick-and-choose the libraries they want to use that would 
not be much of a problem, yet despite all of the discussions around the 
topic - it still isn't.

Perhaps if new, incremental version of Boost.Test was written and 
allowed to stabilize its own interfaces for the next few releases (while 
maintaining interface compatibility for all documented use cases with 
Boost.Test), we could switch to it. Perhaps only by means of changing 
few lines where we #include and/or link, or even better by just picking 
a new version from available boost modules.

Lastly, my impression from reading this whole thread is that Boost.Test 
development has been severly constrained, thus very little improvement 
has taken place even when it was obviously needed. Documentation has 
become a casualty to requirement of keeping the code stable, since there 
is very little motivation for developers to commit changes meant for 
documentation only. Other changes were rarely released, "to avoid 
rocking the boat" in Giennadiy's own words. I don't believe Boost.Test 
is the only library under such constraints.

Clearly some work is needed to enable better development model of such 
"infra-structure" libraries, because even if new test library found its 
place in boost, it would be subject to the same constraints, and we 
would be on square one in few years time - when it's widely adopted, in 
the need of maintenance but severly constrained again!

B.