[test] Passing parameters to fixtures
Hello, 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
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?
TIA, Markus http://lists.boost.org/mailman/listinfo.cgi/boost-users
The simplest approach would be: namespace { struct ConnectToDB_X : F { ConnectToDB_X() : F(db_nameX) {} }; BOOST_FIXTURE_TEST_SUITE( s, ConnectToDB_X ); Hope that helps, Ovanes
Ovanes Markarian wrote:
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?
TIA, Markus http://lists.boost.org/mailman/listinfo.cgi/boost-users
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. Markus
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
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
On Mon, Sep 15, 2008 at 4:22 PM, Markus Schöpflin < markus.schoepflin@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?
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
Ovanes Markarian wrote:
On Mon, Sep 15, 2008 at 4:22 PM, Markus Schöpflin < markus.schoepflin@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, Markus
Markus Schöpflin
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
I would like to state smth here. If I implement a feature using some 3d
party lib (does not matter which one, i.e. Test Framework or not) and the
required functionality is not supported, I just stop my implementation and
ask myself:
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
On Mon, Sep 15, 2008 at 8:08 PM, Gennadiy Rozental
Markus Schöpflin
writes: [...] This is the only type of fixture which is not implemented yet.
Gennadiy
Ovanes Markarian
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.
Gennadiy Rozental wrote:
Markus Schöpflin
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
participants (4)
-
Gennadiy Rozental -
Gennaidy Rozental
-
Markus Schöpflin -
Ovanes Markarian