Re: [boost] Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?

Subject: Re: [boost] Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?
From: Ben Robinson (icaretaker_at_[hidden])
Date: 2011-09-15 03:47:17

>
> Runtime checks for compilability is rather interesting subject. Whether or
> not
> generic component compiles with different inputs is one of the expectations
> and
> it would be nice to be able to test it. Not sure how you are planning to
> achieve
> it though. Can you outline the idea? What are the limitations?
>
> Why does it have to be implemented as BOOST_MPL_ASSERT? Can it be done as a
> separate testing tool? We can consider it for Boost.Test.
>
> Gennadiy
>
> I agree with the feedback that this interface should be separate from the
BOOST_MPL_ASSERT_* family of macros.  I will move the logic I have
implemented out of those macros, and create a similar family of macros, for
unit testing purposes.  These macros will stand on their own, and should be
usable as part of any C++ unit testing framework, including Boost.Test.  For
this discussion, let's assume these new macros have the
name BOOST_MPL_UNITTEST_*.

The idea is to for a meta-program author to write their programs,
using BOOST_MPL_UNITTEST_* to statically assert various predicates and
conditions required by the meta-program.  However, when the unit-tests
instantiate the code, since they will define a symbol to #ifdef on, the
implementation of BOOST_MPL_UNITTEST_* will not generate a compile error,
but will instead instantiate an object which will throw a run-time exception
upon instantiation.

This run-time error can be caught by any capable unit testing framework,
allowing meta-program authors the ability to prove both the success, and
failure conditions of the library under test.  It also allows shipping the
library with classic static assertions in place.

Regards,

Ben Robinson, Ph.D.