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