Re: [Boost-users] [Test] Calling BOOST_MESSAGE too early results in malformed xml output from Boost.Test

Subject: Re: [Boost-users] [Test] Calling BOOST_MESSAGE too early results in malformed xml output from Boost.Test
From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2014-12-26 03:54:29

Martin Ba <0xcdcdcdcd <at> gmx.at> writes:

> 
> Gennadiy Rozental <rogeeff <at> gmail.com> writes:
> >
> > Martin Ba <0xcdcdcdcd <at> gmx.at> writes:
> >
> >>
> >> Hi!
> >>
> >> First, I'm on 1.44 and won't get around to test it on a newer
> >> version any time soon, so I'll just throw it in anyway:
> >>
> >> I've hit the case that when the executable running boost.test is
> >> calling BOOST_MESSAGE from a BOOST_GLOBAL_FIXTURE, the message is
> >> generated
> >
> > As a general rule you are not expected to use testing tools from
> > global fixtures. There used to be issues with test module crashing 
in
> > this case. I do not believe this is the case in later versions, but 
I
> > am not quitesure what you want the framework to do for you here.
> >
> > Gennadiy
> >
> 
> Well, "of course" what I want the framework to do is to make sure it 
> only writes well-formed XML by making sure in the formatter class that 
> the root tag of the XML is always written first. (That was my fix.)

At this point this is not possible. I can't enforce specific order of 
global fixture invocations and I can't enforce global fixtures to appear 
after other test observers appear. 

This should not be an issue for the intended use case. You are not 
expected to performs actual tests in global fixtures.

If you need to abort a test module execution from inside of a global 
test fixture, you can just through an exception, which results in setup 
error being reported by the test module.
 
> Aside:
> 
> Incidentally, with my 1.44 I today discovered that you cannot even 
> invoke `BOOST_CHECK(true)` because that will crash the framework. 
> (That's right, the check passes, but when looking up the current test 
> case in the tool code it will access some uninitialized stuff.)

This should work fine now.
 
> Invoking BOOST_REQUIRE (*_CHECK not so much) from a gobal fixture
> seems quite reasonable to me.

Use exceptions instead. They will abort the test module execution and 
allow you to convey the error message to the invoker.
 
Gennadiy