Subject: Re: [boost] metatest interface update, better Boost.Test integration
From: Ábel Sinkovics (abel_at_[hidden])
Date: 2011-09-27 14:41:20
Hi Ben,
> 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
predicates.
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
> required.
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
code.
Regards,
Abel