Subject: Re: [boost] metatest interface update, better Boost.Test integration
From: Ábel Sinkovics (abel_at_[hidden])
Date: 2011-09-27 14:41:20
> 2) As a meta-test framework, I like the reporting capability, displaying the
> results of each of the unittests. Are these results able to be displayed
> alongside 'regular' BOOST_AUTO_TEST_CASE tests?
The short answer is yes.
The meta_check, meta_warn, meta_require assertions can be used at the
same places as BOOST_CHECK, BOOST_WARN and BOOST_REQUIRE and behave the
same way. They are Boost.Test integration functions for the evaluated
If you use the tree-hierarchy building capability of mpllibs/metatest
(without writing Boost.Test test cases in your code) and use the
<metatest/main_boost.hpp> header, it will add your compile-time test
results to Boost.Test results.
> However, I am unclear exactly how it works, given that any
> BOOST_STATIC_ASSERTS, or BOOST_MPL_ASSERT_* in a library implementation will
> prevent the code from compiling when incorrect types are given. Perhaps I
> have missed something obvious.
If your compile-time predicate fails to compile, you get a compilation
error. I'm not aware of any solution preventing that, metatest can not
do that either. However, for failed predicates it doesn't break the
compilation but gives you a human readable/portable report at runtime.
> 2) Could your framework be modified without too much effort, to catch
> metatest_exceptions, and then add them to your container class, for
> reporting? I imagine this framework element would become part of Boost Test.
> Users of metatest would then be motivated to use Boost Test, but not
I don't understand why to throw a runtime exception - the data (was
there a failed predicate or not) is static.
> 3) Also the MPLLIBS_ADD_TEST macro could become part of Boost Test,
> simplifying the instantiation of test, but again, testing meta-programs
> could still be achieved using the assertion macros alone.
Test metaprograms can be achieved by using static assertions, but based
on my experience displaying a portable/human-readable report of what and
why failed makes life easier.
> I would like to see more examples, collected in a single, easy to find
> directory, which include both the input code, and the printed output
> together, if possible.
I'll implement more examples and upload the outputs somewhere as well
shortly. However, you should be able to just download and build the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk