[Test] Calling BOOST_MESSAGE too early results in malformed xml output from Boost.Test
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 *before* the unit test runner is full initialized (the message "Running ## test cases..." is displayed *after* the Message). When writing xml output, this means that the `<Message>`is generated before the `<TestLog>` root, resulting in malformed xml. I can fix this quite easily on my side, since I've [customized my logger anyway][1], I'll just have to make sure unit_test_log_formatter::log_start is always called first for the xml case, but it's still a buggy thing imho. cheers, Martin [1] : http://stackoverflow.com/questions/26505229/how-to-log-boost-test-output-to-...
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 quite sure what you want the framework to do for you here. Gennadiy
Gennadiy Rozental
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.) 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.) Invoking BOOST_REQUIRE (*_CHECK not so much) from a gobal fixture seems quite reasonable to me. And "of course" what I want the framework to do is to abort the test run if any fixture -- global or not -- fails. As said in the OP, this may work (or not) in the recent version but I sincerely hope that it is not considered "by design" that you cannot invoke test tools from a global fixture (when you *can*, AFAIK, from "normal" fixtures.) cheers, Martin
Martin Ba <0xcdcdcdcd <at> gmx.at> writes:
Gennadiy Rozental
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
participants (2)
-
Gennadiy Rozental -
Martin Ba