On 28/09/2012 07:30, Roland Bock wrote:
On 2012-09-17 16:40, Dave Abrahams wrote:
Hi 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
First of all: We are happy users of Boost.Test!
I haven't counted the number of test cases we handle with Boost.Test in my team, but unless
* there is a replacement * there is tool support for migrating
we would be stuck with the latest version of Boost that offers Boost.Test.
+1. We are currently using Boost.Test for large project and don't plan migrating to anything else. I don't see any major problems with Boost.Test. Futhermore, for simple test cases that we have, its documentation is sufficient. There are few test frameworks with good community support and widespread use, however since many of those are too intrusive there really aren't that many alternatives to Boost.Test, for us. Of course Boost.Test could be improved. e.g. I would not object to being able to write a unit test, with a proper execution monitor, which does not need to link to anything. Perhaps it's just a question of documenting better what Boost.Test already does. If an alternative was provided in some future version of Boost, with nearly-compatible interface (i.e. one which would work with our existing test fixtures and checks), we could consider switch. Without such alternative, we will be stuck on the last version of boost where Boost.Test is available. Simple as that. Also I'd like to raise another point: I rarely follow Boost discussion so am not aware how many times it's been suggested that some library be dropped from boost, but unless such a library is "for internal use only", it would be clearly breaking change which should not be proposed lightly. Boost.Test is not "for internal use only" and removing it would break Boost for many of its users. If Boost was modular library with users able to pick-and-choose the libraries they want to use that would not be much of a problem, yet despite all of the discussions around the topic - it still isn't. Perhaps if new, incremental version of Boost.Test was written and allowed to stabilize its own interfaces for the next few releases (while maintaining interface compatibility for all documented use cases with Boost.Test), we could switch to it. Perhaps only by means of changing few lines where we #include and/or link, or even better by just picking a new version from available boost modules. Lastly, my impression from reading this whole thread is that Boost.Test development has been severly constrained, thus very little improvement has taken place even when it was obviously needed. Documentation has become a casualty to requirement of keeping the code stable, since there is very little motivation for developers to commit changes meant for documentation only. Other changes were rarely released, "to avoid rocking the boat" in Giennadiy's own words. I don't believe Boost.Test is the only library under such constraints. Clearly some work is needed to enable better development model of such "infra-structure" libraries, because even if new test library found its place in boost, it would be subject to the same constraints, and we would be on square one in few years time - when it's widely adopted, in the need of maintenance but severly constrained again! B.