Re: [Boost-users] Boost.Test BOOST_TEST/BOOST_REQUIRE_MESSAGE message arg problems

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:
 > 
https://www.boost.org/doc/libs/1_68_0/libs/test/doc/html/boost_test/tests_organization/fixtures/per_test_suite_fixture.html 

 >
 >
 > 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,
Olaf