Re: [boost] metatest interface update, better Boost.Test integration

Subject: Re: [boost] metatest interface update, better Boost.Test integration
From: Ben Robinson (icaretaker_at_[hidden])
Date: 2011-09-27 02:46:45

On Sat, Sep 24, 2011 at 3:17 AM, Ábel Sinkovics <abel_at_[hidden]> wrote:

> Hi,
>
> Thank you for the feedback about my library so far.

Abel,

Your metatest library has some very interesting capabilities I really like.

1) An implementation detail, mpllibs::metatest::test_result has some very
nice pretty printing capabilites, especially given its information is
gleaned from static data and their types.
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?
3) As a meta-test framework, the MPLLIBS_ADD_TEST convenience macro is very
nice, as it is expressive, and reduces the syntactic complexity of
instantiating a test.

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. I would like to make a suggestion:

Today, I am publishing some macros, which allow otherwise failing asserts,
to instead throw an exception. These macros stand on their own, in the
functionality they provide, and are independent of any unit testing
framework, but room for improvement exists.

1) I would like to explore the possiblity of throwing your mpllibs::
metatest::test_result, or something with similiar capability. This would
still be unit testing framework independent, but would add to the pretty
printing value of the exception.
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.
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.

There is much I like about your metatest library. I believe the macros I am
submitting are complementary, and should probably be integrated into one
submission, so I am sharing the same name metatest. I think your framework
could wrap my framework-independent macros very nicely and provide great
value.

> I've added a new example demonstrating these integration functions. You
> can find it in libs/metatest/example/boost_test_assertion in the source
> tree.
>
> 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'm happy to receive feedback about the new interface. I'm interested if
> people find it useful.
>
> REMOVE_PARENTHESIS is a lifesaver! I have also created another macro which
is similiar:

#define TYPEDEF_AWAY_COMMAS(type_possible_commas, type_no_commas) \
    typedef typename REMOVE_PARENTHESIS(type_possible_commas) type_no_commas

TYPEDEF_AWAY_COMMAS is useful when a nested macro passes in a type which
contains commas in the templated type list. Receive the type surrounded
parentheses, then typedef it into a comma-free-name for all subsequent use.

Both these macros could possibly deserve a submission by themselves,
provided I did not overlook their existence in the library already.

> Regards,
>  Abel
>
>
> Thank you Abel,

Ben Robinson, Ph.D.

> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>