$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-09-15 04:24:52
On Sep 15, 2011, at 3:54 AM, Ben Robinson wrote:
> Thank you for your insight into some additional benefits of this
> capability.
Thank you for making my library properly testable!
> I had not considered the convenience of debugging an actual
> run-time call stack vs. the compiler trace. I will design this library so
> that by setting a single breakpoint in the library, it will always give
> access to the call-stack leading up to the failed assertion.
Oo. Neat. Actually I was just imagining an integrated pretty-print facility like Abel was suggesting, that puts the failed type calculation into the exception string.
For example, one of my typical tests
BOOST_MPL_ASSERT(( mpl::equal<preorder_adj::type, mpl::vector<A,B,C,D,E,F,G,A> > ));
currently fails with
depth_first_search.cpp:85:1: error: No match for 'assertion_failed(
mpl_::failed ************ boost::mpl::equal<
boost::mpl::v_item<G, boost::mpl::v_item<F, boost::mpl::v_item<E, boost::mpl::v_item<D, boost::mpl::v_item<C, boost::mpl::v_item<B, boost::mpl::v_item<A, boost::mpl::vector<mpl_::na>, 0>, 0>, 0>, 0>, 0>, 0>, 0>
, boost::mpl::vector<A, B, C, D, E, F, G, A>
>::************
)'
and instead it could throw an exception that includes the gold inside the ***s.
Then when running the unit test in verbose mode, I could verify that the failures are failing for the right reasons. I don't know much Boost.Test (nor have I looked closely at metatest) but it may even be possible to verify this automatically.
Cheers,
Gordon