Boost logo

Boost :

Subject: Re: [boost] What Should we do About Boost.Test?
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2012-10-01 19:31:32


Dave Abrahams <dave_at_[hidden]> writes:

> 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?

[snip]

> As a straw man, I'll make this suggestion:
>
> - Boost.Test is officially deprecated in the next release

Woah. Stop the train. Are we seriously suggesting deprecating
Boost.Test because, wait ... it has too many features? o_O

> - Its documentation, such as it is, is removed from the release after
> that

It's documentation isn't perfect. But it's better than half the libraries
in Boost that we use and love.

> - Meanwhile, other tests in Boost that use this library are rewritten to
> use a different mechanism

Like what? I've tried them all. Boost.Test is unlike any other. It
completely changed how I code for the better. Every time I find myself
wishing it had a feature, I root around a little and find that it
already did! It's a true gem.

Could it be better? Sure. Which library couldn't.

> - The code is removed from Boost thereafter

-1 This terrifies me. We have thousands of test cases written for
Boost.test. Roughly a third of our code for any given project is unit
test code. And, unlike just some other library dependency, unit test
code is pervasive.

In other words, of the third of our code that is unit tests, almost
every single line depends on Boost.Test. We could kiss goodbye to our
projects (or to ever upgrading Boost) if Boost.Test were removed.

Alex


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk