Dave Abrahams <dave@boostpro.com> 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