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: Ábel Sinkovics (abel_at_[hidden])
Date: 2011-09-16 15:00:26

Hi Ben,

> I did want to keep the interface to this capability a single macro
> invocation, without any setup except a #define, since that is as close to
> what developers are already used to with BOOST_MPL_ASSERT_*.  Also, it was
> my assumption that developers are also accustomed to writing test cases for
> when exceptions are thrown/not thrown (at least I am).

When a complex predicate defined inside a macro call has a syntax error,
the compiler doesn't locate it (the error message points to the macro
call). In those cases defining the predicate outside macro calls makes
life easier. The metatest examples contain a TEST_IF_EQUAL macro
implementation
(https://github.com/sabel83/mpllibs/blob/master/libs/metatest/example/misc/inline_test.cpp#L39) which you can use to play with the interface and see the difference between the error messages.

Pretty-printing replaces BOOST_MPL_ASSERT_NOT and
BOOST_MPL_ASSERT_RELATION, since a lazy version of the not_ metafunction
and comparison metafunctions can be used. In case of a failure, the
pretty-printed error message is something like "equal_to<expected_value,
actual_value>". metatest initially contained an extra macro for testing
a predicate returning false, but I've removed it when I realised the
duplicated functionality.

Regards,
  Abel