On 21 Mar 2016 at 16:47, Vinícius dos Santos Oliveira wrote:
I'd like to know if it's mandatory to use Boost.Test if you intend to contribute a library to Boost.
No, but it sure makes the lives of the maintainers much easier once your library is in.
After facing an issue trying to enable compiler santizers on my tests[1] for long enough, I'd like to use a different test library.
According to a survey done by Niall concerning new libs[2], everybody avoids Boost.Test, favouring assert/static_assert.
That was the case at the time of the survey for new C++ 11 or later only libraries. What the case is now, I don't know.
I've been interested in using Catch[3], which is header-only and can be embedded, posing no problem to users (it'd be transparent). I've seen Boost.AFIO (which is not an official Boost library) already uses it.
I've seen lightweight_test is also used within Boost[4].
Lightweight_test's major problem is it can't output an XML dump of its results like Test and CATCH can. That's a pain for the regression testing etc. Note that AFIO, Outcome and all my other Boost-ish libraries use BindLib which is a "Boost-lite" emulation layer. It wraps up CATCH into a Boost.Test set of macros, thus allowing you to write your unit tests as if you are using Boost.Test, but switch them out transparently for CATCH. I develop all my new code against "Boost lite", and in fact I haven't actually touched a copy of Boost itself since last October. Indeed, my lack of recent usage of Boost at all meant I recently had to resign helping maintain Thread on Windows, I just have no need for Boost any more in recent months nor expect to any time in the next year. Certainly AFIO v2 has zero need for Boost any time now or any expected time in the future as I won't be bothering with BoostBook for the docs again, I wasted enough of my life on that for v1. That said, if v2 is ever presented here for entry into Boost, it can be flipped over from Boost-lite onto Boost with just a macro switches. I'd personally recommend you use a similar system of writing your tests for Boost.Test, and the actual underlying test engine can be that or anything else.
If Boost.Test ever fix its integration problem with compiler sanitizers[1], I'd have no problem migrating everything back again to Boost.Test. However, it's more important for me to have this issue solved now so I can jump to the next task (valgrind and fuzz testing).
I can verify my setup is clean for the sanitisers as AFIO v1 used those extensively. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/