[test] Not using Boost.Test for an official Boost library
Hi list, I'd like to know if it's mandatory to use Boost.Test if you intend to contribute a library to Boost. 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. 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]. 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've also seen that some header-only libraries use a different build system for the test target[5] and using a header-only test library would be a lesser demand that should be okay. [1] https://svn.boost.org/trac/boost/ticket/11425 [2] https://raw.githubusercontent.com/boostcon/cppnow_presentations_2015/master/... [3] https://github.com/philsquared/Catch [4] http://www.boost.org/doc/libs/1_60_0/libs/core/doc/html/core/lightweight_tes... [5] https://github.com/boostorg/hana/blob/63c5f87dfdadd07e496cefefc63c3ea9968d31... -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
On Mon, Mar 21, 2016 at 2:47 PM, Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:
I'd like to know if it's mandatory to use Boost.Test if you intend to contribute a library to Boost.
It's not. But anything you use must not be external nor violate the licensing requirements. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Monday, March 21, 2016 2:54 PM, Rene Rivera
On Mon, Mar 21, 2016 at 2:47 PM, Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:
I'd like to know if it's mandatory to use Boost.Test if you intend to contribute a library to Boost.
It's not. But anything you use must not be external nor violate the
licensing requirements.
It would be nice if boost could approve a small set of testing libraries that could be used externally, instead libraries copying headers.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Le 21/03/16 20:47, Vinícius dos Santos Oliveira a écrit :
Hi list,
I'd like to know if it's mandatory to use Boost.Test if you intend to contribute a library to Boost.
Hi, As one of the boost.test maintainer, I can say boost.test is not mandatory.
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.
I think it would be good you look into the ticket once more. The problem looks like being a false negative of clang, since I cannot reproduce the issue with valgrind. Also, as pointed in this same ticket, I am still waiting for you to try with valgrind. Here is the summary of the error: ====== SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/travis/build/vinipsmaker/asiohttpserver/boost-release-master/boost/smart_ptr/detail/sp_counted_base_clang.hpp:112 boost::detail::sp_counted_base::release() ====== because boost.test includes smart_ptrs'.
According to a survey done by Niall concerning new libs[2], everybody avoids Boost.Test, favouring assert/static_assert.
I did not attend to that talk, do you have the context of that particular slide and what was really meant by this single sentence? It is hard to tell from the PDF I just downloaded.
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].
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).
The ball is on your side. I can still try with intel inspector, maybe tomorrow.
I've also seen that some header-only libraries use a different build system for the test target[5] and using a header-only test library would be a lesser demand that should be okay.
Boost.test can be used header only, please have a look here: http://www.boost.org/doc/libs/1_60_0/libs/test/doc/html/boost_test/usage_var... Regards, Raffi
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/
It's not mandatory to use Boost.Test but it's widely understood and generally effective and suitable. A lack of enthusiasm built up because of various bugs in Boost.Test that were not resolved as quickly as many would have liked. However, it is now quite stable, actively maintained and has new and much improved documentation, so you can use it with confidence. Using Boost static_assert does not conflict with using Boost.Test and is usually worthwhile protection against abuse by users. To use the invaluable Boost suite of testers, allowing users to see in fine detail what works on what platforms, you will need to use b2/bjam, providing jamfile for the /test folder (and ideally also for /example folder). (Aside: I note that there are many libraries that does not provide a jamfile to allow users to run all the examples quickly and easily. I'd like to see this done for all libraries.) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vinícius dos Santos Oliveira Sent: 21 March 2016 19:47 To: Boost Subject: [boost] [test] Not using Boost.Test for an official Boost library
Hi list,
I'd like to know if it's mandatory to use Boost.Test if you intend to contribute a library to Boost.
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.
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].
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've also seen that some header-only libraries use a different build system for the test target[5] and using a header-only test library would be a lesser demand that should be okay.
[1] https://svn.boost.org/trac/boost/ticket/11425 [2] https://raw.githubusercontent.com/boostcon/cppnow_presentations_2015/master/... Boost-libraries-Fiber-AFIO-DI-and-APIBind.pdf [3] https://github.com/philsquared/Catch [4] http://www.boost.org/doc/libs/1_60_0/libs/core/doc/html/core/lightweight_tes... [5] https://github.com/boostorg/hana/blob/63c5f87dfdadd07e496cefefc63c3ea9968d31...
-- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (6)
-
Niall Douglas -
Paul A. Bristow -
paul Fultz -
Raffi Enficiaud -
Rene Rivera -
Vinícius dos Santos Oliveira