On Sat, Sep 24, 2011 at 3:17 AM, Ábel Sinkovics <abel@elte.hu> wrote:
Hi,
Thank you for the feedback about my library so far.
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
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. 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