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

Subject: Re: [boost] What Should we do About Boost.Test?
From: Timo H. Geusch (timo_at_[hidden])
Date: 2012-09-17 12:49:18

On 17.09.2012 07:40, Dave Abrahams wrote:
> Hi All,
>
> I was just going through Boost.Test to try to figure out how to teach
> it, and while it looks to have substantial value, it is also in quite 
> a
> mess.  It contains loads of features that are exercised in the 
> examples/
> directory but neither included in any of the tests nor documented.
> There are facilities for command-line argument parsing!  There are
> "decorators" that turn on/off features for test cases.  There is 
> support
> for mock objects! These are cool and sometimes necessary features, 
> but
> who knew?

I agree that this is a massive problem - I've been using Boost.Test for 
quite a while and the team I work in uses it for testing of our 
project's code, but I didn't know that half these features were 
available.

> 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

As has been mentioned, is there any alternative in sight? And if there 
is, what is the migration path especially for people who might have a 
few thousand unit tests?

There's also the question of infrastructure. Boost.Test has at least 
some support from some CI systems (for example, we're using Jenkins and 
thanks to an existing plugin, it can parse the XML output generated by 
Boost.Test. I would argue that a replacement probably either needs to 
support the same output format or at least an easy way to support this 
sort of post-processing.

> - The code is removed from Boost thereafter

Unless there is a migration path that would make it easy to get off 
Boost.Test and onto another framework that would offer similar benefits 
(and integration with CI systems, etc etc), I'm not sure that this a 
good idea. Putting it into a deprecated section with a clear line drawn 
in the sand saying "no further development, if it breaks you're on your 
own" is probably a better approach.