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.