Boost logo

Boost :

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
(970) 461-2000 main
(970) 612-2327 direct

Boost list run by bdawes at, gregod at, cpdaniel at, john at