Re: [Boost-users] Ideas for UT needed

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

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

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

>Thank you Richard,

No problem.  If you want more insight into my approach to using
Boost.Test for C++, you can read the 5 part series I wrote on my blog:
<http://legalizeadulthood.wordpress.com/2009/07/04/c-unit-tests-with-boost-test-part-1/>
<http://legalizeadulthood.wordpress.com/2009/07/05/c-unit-tests-with-boost-test-part-2/>
<http://legalizeadulthood.wordpress.com/2009/07/05/c-unit-tests-with-boost-test-part-3/>
<http://legalizeadulthood.wordpress.com/2009/07/05/c-unit-tests-with-boost-test-part-4/>
<http://legalizeadulthood.wordpress.com/2009/07/05/c-unit-tests-with-boost-test-part-5/>

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

This is referring to the fact that every test case defines a class.
The test case class derives from the fixture class.  The fixture is
just the place where code and data common to multiple tests cases is
conveniently located in order to eliminate duplication.

While it is certainly possible to have your test fixture derive from
the SUT, I would not recommend this as a good practice.  Inheritance
is the tightest form of coupling that you can have.

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

There's nothing that says all your setup has to be in the c'tor of the
fixture.  You can have the fixture c'tor do basic setup and then
provide a method on the fixture that does the variable part.  Just
have your fixture reference the SUT by auto_ptr<> or shared_ptr<> (so
that the fixture d'tor automatically releases the SUT).

>> I assume here that 'test' is a method on your fixture.
>
>in principle yes, there is a
>
>struct test {
>    bool operator(...);
>};

If you have this test structure to eliminate duplicated code from test
case to test case, then it may be easier to have this code located
within the fixture shared between test cases.  It would depend on the
specific code in question, but if it's a method on the fixture, then
it has access to all the data members on the fixture, so you wouldn't
need to repeatedly pass them into this test structure in every test
case.  Here I'm talking about eliminating the duplicated argument
lists to test::operator() that would appear in every test case.

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

OK, this sounds more like a question of how to organize your
lexer/parser combination and how to manage their lifetimes.  The
Spirit mailing list might be a better place to get an answer to that
question.  I am a novice Spirit user, but I don't have any specific
suggestions or guidance for this.
-- 
"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>