Re: [Boost-users] naming a test

Subject: Re: [Boost-users] naming a test
From: Eric Prud'hommeaux (eric_at_[hidden])
Date: 2014-05-28 04:21:06

* Richard <legalize+jeeves_at_[hidden]> [2014-05-27 23:20+0000]
> Eric Prud'hommeaux <eric_at_[hidden]> spake the secret code
> <20140527203520.GX5022_at_[hidden]> thusly:
> 
> >* Richard <legalize+jeeves_at_[hidden]> [2014-05-27 19:15+0000]
> >> 
> >> Do you really need to build the test case tree by hand?
> >
> >Generally, yes. I'm working from standard test suites and it makes
> >more sense to read them from the manifest than to write some emacs
> >macro to turn the manifest into procedural code.
> 
> I see.
> 
> >> >. I used the preprocessor output to override the 2nd arg to
> >> >make_test_case with a name of my choosing:
> >> >    ts->add(boost::unit_test::make_test_case
> >> >            (boost::unit_test::callback0<>
> >> >             (boost::bind( &free_test_function, 1, 2)),
> >> >             boost::unit_test::const_string( minor, 1)));
> 
> The arguments to boost::unit_test::const_string are the char const*
> pointer to the string and the number of characters in the string.
> (For a C style string literal "foo" this is sizeof("foo")-1 which
> evaluates to 3.)
> 
> Did you really mean to pass in 1 as the number of characters?

Yes, but just because my original attached example had trivial names
constructed by crossing the chars in argv[1] and argv[2], e.g.
  abc 12 -> a1 b1 c1 a2 b2 c2.

> boost::unit_test::const_string takes a C-style string literal and
> provides std::string style compatible semantics (i.e. iterators,
> length property, etc.).
> 
> You can think of BOOST_TEST_CASE as just a more convenient way of
> invoking the constructor for boost::unit_test::test_case:
> <http://user.xmission.com/~legalize/boost.test/libs/test/doc/html/test/reference/test_classes/test_case.html>
> 
> I don't see any reason why you couldn't invoke the constructor
> directly.

That makes sense. I wonder why the macros invoke make_test_cast, which
then invokes the constructor:

from boost/test/unit_test_suite_impl.hpp:252:
  inline test_case*
  make_test_case( callback0<> const& test_func, const_string tc_name )
  {
      return new test_case( ut_detail::normalize_test_case_name( tc_name ), test_func );
  }
, maybe some mechanical constraints on invoking constructors from
macros?

In case anyone's following along now or in the future, the example
posted at the head of this thread works with the test_case constructor
invoked directly (note swapped order of args):

  using make_test_case:
            ts->add(boost::unit_test::make_test_case
                        (boost::unit_test::callback0<>
                         (boost::bind( &free_test_function, 1, 2)),
                         boost::unit_test::const_string( minor, 1)));

  constructing test_case directly:
            ts->add(new boost::unit_test::test_case
                    (boost::unit_test::const_string( minor, 1),
                     boost::unit_test::callback0<>
                     (boost::bind( &free_test_function, 1, 2))));

Thanks, Richard!

> As for how fragile all of this is -- your guess is as good as mine;
> I'm not the implementor of the library.
> -- 
> "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
>      The Computer Graphics Museum <http://computergraphicsmuseum.org>
>          The Terminals Wiki <http://terminals.classiccmp.org>
>   Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- 
-ericP
office: +1.617.599.3509
mobile: [phone]
(eric_at_[hidden])
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.