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

Subject: Re: [boost] What Should we do About Boost.Test?
From: Dave Steffen (dave.steffen_at_[hidden])
Date: 2012-09-18 11:56:13

On 09/17/2012 08:40 AM, Dave Abrahams wrote:
>
> Hi All,
[...]

> 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

Please no.  I understand your reasoning, and agree with many critiques 
of the library.  However, we've been using Boost.Test for years now (I 
think we were one of the early adopters) and have hundreds of test 
suites with thousands of test cases. Changing to a different unit test 
system is simply not possible right now (nor, I suspect, in the near 
future); we're too heavily invested, and we're extremely 
developer-limited right now.

Like it or not, Boost.Test is part of Boost, and we (for one) are 
relying on it to stay that way.  I don't think you can deprecate it 
until you've got a replacement *and* a halfway-decent migration path. 
(Granted, that replacement might be in a different library

Yes, Boost.Test has its blemishes. Most of the big problems have already 
been mentioned -- mainly the documentation, also the interface changes 
(but those were a long time ago).  IIRC, four or five years ago Gennadiy 
and I agreed to disagree about the floating point comparison macros. 
We've added our share of customizations and tweaks.  But we like the 
library very much.  It does what we need it to do, and at this point we 
don't think about it much -- which is exactly what you want your unit 
test library to be like.

If someone is going to write a replacement, we'd be very interested in 
providing ideas, feedback, and possibly even programmer hours.

But, please don't take it away without having something else to take its 
place. (If that 'something else' is in a completely different library, 
e.g. googletest, fine -- but Boost.Test users still need a good 
migration path). If the biggest problem is documentation, it seems that 
fixing the documentation, or even living with bad documentation, is a 
lesser evil (or at least less extreme) than throwing it out completely.

-- 
Dave Steffen
Software Engineer
NUMERICA CORPORATION
www.numerica.us
[phone] main
[phone] direct