[Boost-users] [test] Passing parameters to fixtures
Markus Schöpflin
to set up and tear down database connections for unit tests, I need
something like parametrized test fixtures.
Up to now (using an old version of Boost.Test) I was creating a customized
test suite (by deriving from test_suite) and performed the connection
handling during construction/destruction of the customized test suite.
As the latest Boost.Test now has explicit support for test fixtures, I was
looking at how I could replace my old approach by using a test suite fixture.
The fixture would need to look something like this:
struct F {
F(string db_name) { connect to db_name }
~F() { disconnect from db_name }
};
Now, the Boost.Test documentation tells me that a fixture is supposed to be
used like this: BOOST_FIXTURE_TEST_SUITE( s, F )
So there doesn't seem to be a way of passing parameters to the constructor
of the fixture. Is there any? Or is there any other way to obtain a
parametrized fixture? Or should I just keep on using customized test suites?
TIA, Markus
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ovanes Markarian
The fixture would need to look something like this:
struct F {
F(string db_name) { connect to db_name }
~F() { disconnect from db_name }
};
Now, the Boost.Test documentation tells me that a fixture is supposed to be used like this: BOOST_FIXTURE_TEST_SUITE( s, F )
So there doesn't seem to be a way of passing parameters to the constructor of the fixture. Is there any? Or is there any other way to obtain a parametrized fixture? Or should I just keep on using customized test suites?
TIA, Markus
namespace {
struct ConnectToDB_X : F
{
ConnectToDB_X() : F(db_nameX)
{}
};
BOOST_FIXTURE_TEST_SUITE( s, ConnectToDB_X );
Hope that helps,
Ovanes
Markus Schöpflin
> Hi!
>
>
> The fixture would need to look something like this:
>> struct F {
>> F(string db_name) { connect to db_name }
>> ~F() { disconnect from db_name }
>> };
>>
>> Now, the Boost.Test documentation tells me that a fixture is supposed to be
>> used like this: BOOST_FIXTURE_TEST_SUITE( s, F )
>>
>> So there doesn't seem to be a way of passing parameters to the constructor
>> of the fixture. Is there any? Or is there any other way to obtain a
>> parametrized fixture? Or should I just keep on using customized test suites?
>>
>>
>
> The simplest approach would be:
> namespace {
> struct ConnectToDB_X : F
> {
> ConnectToDB_X() : F(db_nameX)
> {}
> };
>
> BOOST_FIXTURE_TEST_SUITE( s, ConnectToDB_X );
I guess I forgot to mention that I need to configure the fixture at
runtime. The DB name (which is actually a connection string) is passed to
the test as a command line parameter.
Ovanes Markarian
I guess I forgot to mention that I need to configure the fixture at runtime. The DB name (which is actually a connection string) is passed to the test as a command line parameter.
Markus
Just implement in your fixture a protected member called init_db(string_type const& db_name);
This member can be called from the suite's body, since AFAIK it derives from it.
With Kind Regards,
Ovanes
Markus Schöpflin
>> I guess I forgot to mention that I need to configure the fixture at
>> runtime. The DB name (which is actually a connection string) is passed to
>> the test as a command line parameter.
>>
> Just implement in your fixture a protected member called init_db(string_type
> const& db_name);
>
> This member can be called from the suite's body, since AFAIK it derives from
> it.
But hasn't the fixture already been constructed then? So using the
constructor of the fixture for setting up the DB connection will not be
possible. Or did I get you wrong?
Thanks for your help,
Ovanes Markarian
Ovanes Markarian wrote:
I guess I forgot to mention that I need to configure the fixture at
runtime. The DB name (which is actually a connection string) is passed to
the test as a command line parameter.
Just implement in your fixture a protected member called init_db(string_type
const& db_name);
This member can be called from the suite's body, since AFAIK it derives from
it.
But hasn't the fixture already been constructed then? So using the constructor of the fixture for setting up the DB connection will not be possible. Or did I get you wrong?
Thanks for your help,
Markus
Yes, but who said, that you must use the constructor for connection initialization? You can also go another way and have you suite without fixture specification, but initialize the fixture in the first line of your suite:
BOOST_TEST_....()
{
Fixture f(pass the name of db connection);
}
Best Regards,
Ovanes
Markus Schöpflin
> On Mon, Sep 15, 2008 at 4:22 PM, Markus Schöpflin <
> markus.s...@comsoft.de> wrote:
>
>> Ovanes Markarian wrote:
>>
>> I guess I forgot to mention that I need to configure the fixture at
>>>> runtime. The DB name (which is actually a connection string) is passed to
>>>> the test as a command line parameter.
>>>>
>>>> Just implement in your fixture a protected member called
>>> init_db(string_type
>>> const& db_name);
>>>
>>> This member can be called from the suite's body, since AFAIK it derives
>>> from
>>> it.
>>>
>> But hasn't the fixture already been constructed then? So using the
>> constructor of the fixture for setting up the DB connection will not be
>> possible. Or did I get you wrong?
>>
> Yes, but who said, that you must use the constructor for connection
> initialization? You can also go another way and have you suite without
> fixture specification, but initialize the fixture in the first line of your
> suite:
>
> BOOST_TEST_....()
> {
> Fixture f(pass the name of db connection);
> }
Wouldn't this be a test case instead of a test suite? I need to share the
fixture across multiple test cases, so I need the fixture to live at suite
level.
Anyway, the Boost.Test documentation suggests that fixture setup should be
done in the constructor, and teardown in the destructor, so IMHO it would
be the logical place for this kind of work.
As it looks now, using a fixture (which seems to be the recommended way
now) doesn't allow me the same level of control as deriving from test_suite
and setting up the fixture there (which has been the recommended way in the
past).
And I don't see a way how one would integrate a runtime parametrized
fixture into the BOOST_AUTO_TEST_... framework with the current API.
As long as deriving from test_suite still works, I'm fine with that. But as
this approach is no longer documented, I am a bit worried that it will no
longer work in a future version of Boost.Test.
Thanks,
Gennadiy Rozental
[...]
> Up to now (using an old version of Boost.Test) I was creating a
> test suite (by deriving from test_suite) and performed the
> connection handling during construction/destruction of the
> customized test suite.
[...]
> Now, the Boost.Test documentation tells me that a fixture
> is supposed to be used like this: BOOST_FIXTURE_TEST_SUITE( s, F )
Unfortunately this is not what you want. This suite level fixture -
meaning it's applied to every test case within the suite. What you
are looking for is "per suite" fixture. This is the only type of
fixture which is not implemented yet.
> So there doesn't seem to be a way of passing parameters to
> the constructor of the fixture. Is there any? Or is there
> any other way to obtain a parametrized fixture? Or should
> I just keep on using customized test suites?
Unless I've broken something, it should continue to work.
On the other hand if you need yo configure DB connection
only once per test module, you can use BOOST_TEST_GLOBAL_FIXTURE.
You can access CLAs through master test suite interface.
Gennadiy
Ovanes Markarian
Is it really needed? Should I really proceed with the implementation? What are the alternatives?
As practice has shown, I usually find a better and much cleaner solution. This is not a direct answer to this post and usually in the Boost Groups people do not criticize, but just give advices to solve concentrate problems, but in my opinion, if this features was not requested for some years, this might be a wrong implementation direction.
With Kind Regards,
Ovanes
Markus Schöpflin <markus.schoepflin <at> comsoft.de> writes:
[...]
This is the only type of fixture which is not implemented yet.
Gennadiy
Gennaidy Rozental
> in my opinion, if this features was not requested for some years,
> this might be a wrong implementation direction.
In general good sentiment.
In this particular case: suite level fixture is indeed kinda esoteric use case,
but for completeness it might be worth implementing. I can see why one would
want to use it. That being said, I did not find yet reasonably simple way to
implement it ;)
Gennadiy.
Markus Schöpflin
> Markus Schöpflin <markus.schoepflin <at> comsoft.de> writes:
>
> [...]
>
>> Up to now (using an old version of Boost.Test) I was creating a
>> test suite (by deriving from test_suite) and performed the
>> connection handling during construction/destruction of the
>> customized test suite.
>
> [...]
>
>> Now, the Boost.Test documentation tells me that a fixture
>> is supposed to be used like this: BOOST_FIXTURE_TEST_SUITE( s, F )
>
> Unfortunately this is not what you want. This suite level fixture -
> meaning it's applied to every test case within the suite. What you
> are looking for is "per suite" fixture. This is the only type of
> fixture which is not implemented yet.
Yes, you're right. I assumed that this would give me a per suite fixture.
>> So there doesn't seem to be a way of passing parameters to
>> the constructor of the fixture. Is there any? Or is there
>> any other way to obtain a parametrized fixture? Or should
>> I just keep on using customized test suites?
>
> Unless I've broken something, it should continue to work.
OK.
> On the other hand if you need yo configure DB connection
> only once per test module, you can use BOOST_TEST_GLOBAL_FIXTURE.
> You can access CLAs through master test suite interface.
Interesting. I didn't think about that before. So the global fixture would
parse the command line itself and set up the DB connection in the constructor.
This should give me exactly what I need.
Thanks for your help,
Markus
_______________________________________________