Re: [Boost-users] Ideas for UT needed

Subject: Re: [Boost-users] Ideas for UT needed
From: Richard (legalize+jeeves_at_[hidden])
Date: 2013-02-13 16:05:21

[Please do not mail me a copy of your followup]

boost-users_at_[hidden] spake the secret code
<511BE2CF.9050802_at_[hidden]> thusly:

>My fixture looks so far:
>
>---8<---
>     typedef std::string::const_iterator base_iterator_type;
>     typedef my_tokens<base_iterator_type> lexer_type;
>     typedef lexer_type::iterator_type iterator_type;
>     typedef error_handler<base_iterator_type, iterator_type>
>                                             error_handler_type;
>
>     struct fixture
>	    : private boost::base_from_member<error_handler_type>,
>	      private boost::base_from_member<lexer_type>,
>	      my_grammar<iterator_type, lexer_type>

"Prefer aggregation over inheritance" for me means that my test
fixtures don't derive from the SUT, they have the SUT as a member.

In your case, you might want to have the SUT as an auto_ptr so that
you can allocate it dynamically during each test case instead of at the
time the test case itself is constructed.  The auto_ptr (or shared_ptr
if you prefer) will destroy the SUT at the end of each test case.

Going through all this trouble of using base_from_member just so you
can derive from the SUT(s) seems overly complex.

But the basic idea is that yes, your test fixture is constructed without
arguments, so if you don't know them at the time the fixture is
constructed, you provide member functions on your fixture that handle
the duplication between test cases with the variation supplied as
parameters.

>error_handler_base::member requires therefore the iterators first/last. 
>How to give them? In the UT I have further a "test" function object so I 
>can use e.g. it like here:
>
>---8<---
>BOOST_FIXTURE_TEST_SUITE(parameter_test, fixture)
>
>BOOST_AUTO_TEST_CASE(my_test) {
>
>     BOOST_CHECK(test(rule_to_test,
>                     "input to parse",
>                     "expected output"));
>}

I assume here that 'test' is a method on your fixture.

>The next problem is related to the original use case. conjure2 is design 
>as a compiler: initialize, analyse, generate and exit - no reuse of the 
>grammar. I like to instance the grammar once (static) and use it several 
>times using the qi::parse function. Since the iterators are fixed, they 
>can't be changed later to point to other sources, isn't it? Is this the 
>right approach for my problem?

I'm not sure I understand this question; are you asking how to unit
test your compiler?
-- 
"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>