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_or...
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