Re: [boost] [test] Not using Boost.Test for an official Boost library

Subject: Re: [boost] [test] Not using Boost.Test for an official Boost library
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2016-03-21 16:28:27

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_variants.html#boost_test.usage_variants.single_header

Regards,
Raffi