[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code <511C9FB4.6090000@gmx.de> 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-te... http://legalizeadulthood.wordpress.com/2009/07/05/c-unit-tests-with-boost-te... http://legalizeadulthood.wordpress.com/2009/07/05/c-unit-tests-with-boost-te... http://legalizeadulthood.wordpress.com/2009/07/05/c-unit-tests-with-boost-te... http://legalizeadulthood.wordpress.com/2009/07/05/c-unit-tests-with-boost-te...
"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/fixtu.... 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