Boost logo

Boost Users :

Subject: Re: [Boost-users] Boost.Test BOOST_TEST/BOOST_REQUIRE_MESSAGE message arg problems
From: Olaf Peter (ope-devel_at_[hidden])
Date: 2018-08-27 05:58:10

>>> Boost.Test ships a BOOST_DATA_TEST_CASE_F() macro for this case,
>>> which is a 'local' fixture, each time constructed and destroyed which
>>> is expensive - so I like the idea of a global fixture to save to
>>> filesystem. Even I've installed it as global one too the events are
>>> doubled... but I can see that the test observer shows the test status
>>> followed by the call to failure_diagnostic - so the concept works.
>>> To reduce it: How can I access a member function of global fixture on
>>> a compilation unit layout shown above.
>> even the use of
>> BOOST_FIXTURE_TEST_SUITE( my_testsuite, test_observer_fixture )
>> seems to create/destroy the fixture for each test case.
> This one:

> does it once per test suite. However it is isolated from the test case.
> The fact that a test case body can access the fixture is not a very good
> pattern and has several caveats (although very convenient). For
> instance, as you can observe, global fixtures and test case/suite
> fixtures do not have the same isolation.
> If you want to access the global fixture, you have to expose your
> fixture globally, provide some static member function that return a
> pointer to a singleton. The test framework itself will not create more
> than one instance.

This concept is shown at the documentation, using a singleton would
solve the problem with the access.

> But I am a bit lost in what you are doing, and to me this does not go to
> the right direction. If the test module is very complicated to maintain,
> it reduces the chances to be useful, steady and stable on the long run.
> When I look back, I can see one of the comment in the code that says:
> // call diagnostic only in failure case and write then
> This means to me that a fixture should be executed for each test case.
> The purpose of the fixture would be to write the diagnostic in case of a
> failure.

Yes, this was the intent. I solved the problem using
BOOST_DATA_TEST_CASE_F where the fixture self has no member/empty
constructor. The relevant code will be (delayed) instanciated inside the
failure_diagnostic(...) member function. This gives clean design too :)

So, thanks for your help and ideas,

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at