Re: [boost] Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?

Subject: Re: [boost] Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?
From: Ábel Sinkovics (abel_at_[hidden])
Date: 2011-09-13 14:33:55

Hi Dave,

> If you're just checking MPL assertions, then presumably there's a
> predicate that can be evaluated without throwing.  Why not just feed
> those predicates' results to regular runtime assertions?

In addition to feeding those predicates to runtime assertions a type
pretty-printing utility can be used to provide more detail on why the
predicate failed. Relying on a pretty-printer rather than the compiler
error messages makes the output standard across platforms/compilers and
more readable in many cases.

For example for the following predicate:

typedef equal_to<int_<13>, function_to_test<int_<7> >::type> p;

it can provide a reason like "equal_to<int_<13>, int_<11> >" compared to
a verbose compiler error message containing the point somewhere. The
difference becomes more significant when there are more failed
predicates and a unit testing report can list and clearly separate the
failed test cases (and their reasons) from each other. I found this very
useful while I was developing metaprogramming libraries.

This thing can be wrapped by something (template function, macro, etc)
taking the predicate as a nullary metafunction. That wrapper can either
give the result of the predicate and the pretty-printed reason to a
runtime assertion or collect them somewhere. In the latter case, an
integration tool can feed them to runtime assertions which makes
template metaprogramming tests independent of the tool being used to
test runtime code.

Regards,
  Abel