
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