Beman Dawes wrote: On Fri, Aug 8, 2014 at 9:53 AM, Peter Dimov wrote:

...

Beman Dawes wrote:

...

Certain library function errors are difficult to regression test because it is not obvious how to observe their behavior in a test framework. Examples include:

...

2) Verification that BOOST_ASSERT fires when a precondition is violated.

You can do this by enabling a custom assert handler and then test that it has been invoked.

Yes, but the question in my mind is how to "test that it has been invoked"?

I just do the obvious: increment an "assertion_failed_" global variable in the handler, then BOOST_TEST that it has been incremented the correct number of times. It's a bit ad-hoc, but it works.

On Fri, Aug 8, 2014 at 10:39 AM, Beman Dawes wrote:

On Fri, Aug 8, 2014 at 9:53 AM, Peter Dimov wrote:

...

Beman Dawes wrote:

...

...

2) Verification that BOOST_ASSERT fires when a precondition is violated.

...

You can do this by enabling a custom assert handler and then test that it has been invoked.

Yes, but the question in my mind is how to "test that it has been invoked"?

That involves some mutually agreed upon way for the handler to inform the test framework that it has been invoked, and possibly the other information available. Is there a packaged way to handle that communication, or at least a pattern for such back channel communication? Or do I have to figure it out from scratch every time the need arises?

I can't help thinking that coroutines might be helpful for this back-channel communication. Minimally, one could launch the test case on an asymmetric coroutine, establishing a BOOST_ASSERT handler that passes control back to the main test logic. For bullet 3, it would be great to be able to intercept control at the API level, pass control back to the main test logic and allow it the opportunity to inject errors (or data) to be verified. That might require a pair of symmetric coroutines. But to me, the harder part is the dependency injection.