I'm using cppunit to test a plugin-based systems, where plugins communicate via a central object. I've mocked out this central object so as to test the each plugin individually - I can capture the messages that are sent by each plugin. These messages are supposed to be well-formed XML, so I would like the mock central object to run an XML parser on all messages it captures. I'd like to cause a cppunit assertion failure if the parser indicates bad XML - I'm using a CPPUNIT_ASSERT statement to do so.
To make matters more complicated, this message sending/assertion is happening in a different thread than the thread the test fixture is running in - I've used a sleep to delay the fixture thread long enough for this to occur. Running through the test in debug mode, it's clear what happens - when I trigger the CPPUNIT_ASSERT, the thread it occurs in drops dead. My test fixture thread isn't aware of this in any way, and continues on.
Anybody think there's any hope of getting this working? I can certainly get around it by simply setting a variable when the parsing fails and doing an assertion on that variable from the test fixture. This way would be much slicker - every test that involved sending a message would automatically pick up the XML validation test.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only way to pass a failed assertion between thread is to pass the failure data between the thread.
I see mostly two ways to go about it:
1) set a simple variable when the failure occurs and don't bother with assertion (this is somewhat similar to the 'log' test pattern.
2) catch the assertion exception in the spawned thread, pass its content to the test thread and rethrow it.
Baptiste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the input. The MockObject's actually being called by the Windows WMI subsystem, in response to an asyncronous query, so I have very limited control over what's going on in there. I ended up simply setting a flag when the error occurs and checking for it aftewards, as you said. It's slightly more cumbersome to use, but seems to be the only solution that works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using cppunit to test a plugin-based systems, where plugins communicate via a central object. I've mocked out this central object so as to test the each plugin individually - I can capture the messages that are sent by each plugin. These messages are supposed to be well-formed XML, so I would like the mock central object to run an XML parser on all messages it captures. I'd like to cause a cppunit assertion failure if the parser indicates bad XML - I'm using a CPPUNIT_ASSERT statement to do so.
To make matters more complicated, this message sending/assertion is happening in a different thread than the thread the test fixture is running in - I've used a sleep to delay the fixture thread long enough for this to occur. Running through the test in debug mode, it's clear what happens - when I trigger the CPPUNIT_ASSERT, the thread it occurs in drops dead. My test fixture thread isn't aware of this in any way, and continues on.
Anybody think there's any hope of getting this working? I can certainly get around it by simply setting a variable when the parsing fails and doing an assertion on that variable from the test fixture. This way would be much slicker - every test that involved sending a message would automatically pick up the XML validation test.
The only way to pass a failed assertion between thread is to pass the failure data between the thread.
I see mostly two ways to go about it:
1) set a simple variable when the failure occurs and don't bother with assertion (this is somewhat similar to the 'log' test pattern.
2) catch the assertion exception in the spawned thread, pass its content to the test thread and rethrow it.
Baptiste.
Thanks for the input. The MockObject's actually being called by the Windows WMI subsystem, in response to an asyncronous query, so I have very limited control over what's going on in there. I ended up simply setting a flag when the error occurs and checking for it aftewards, as you said. It's slightly more cumbersome to use, but seems to be the only solution that works.