Re: [Boost-users] Ideas for UT needed

Subject: Re: [Boost-users] Ideas for UT needed
From: Olaf Peter (ope-devel_at_[hidden])
Date: 2013-02-14 03:26:28

Thank you Richard,

>> 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.

yes, the inheritance approach comes from my understanding (which may be 
wrong) of the usage of fixture, 
http://www.boost.org/doc/libs/1_53_0/libs/test/doc/html/utf/user-guide/fixture/test-suite-shared.html. 
But it may not exclude aggregation.

> 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

this is my problem ...

> constructed, you provide member functions on your fixture that handle
> the duplication between test cases with the variation supplied as
> parameters.

I will check this.

>> 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.

in principle yes, there is a

struct test {
    bool operator(...);
};

FO, the fixture provides only the grammar etc. prerequisites.

>> 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?

No, my goal is to instance once on demand and use these lexer/grammer 
etc. to parse more than once different inputs; simply reuse. My UI 
program is closed by the user, than the main and therefore grammar 
instance is destroyed. On compilers (like conjure2 example) after eject 
the code the task is finished and program is closed. If one wish to 
compile multiple files one executes the compiler binary more than once - 
each time creating new instances. Hopefully my intentions are more clear.

Thanks,
Olaf