[...]

Frankly i am not sure I understand the original incentive. Run the test without
the debugger. It'll report the line number for the failure. Then just set a
breakpoint at this line. This way you can actually debug into a failing call
instead of looking at post-effect of failed validation inside the Boost.Test.

The code that I was working with uses a common test function that is called multiple times with different inputs, making it more difficult to breakpoint that single line.  Is there a reason not to provide abort() or similar functionality?

Just to offer you a quick workaround: you can raise a conditional signal "raise(SIGINT)". Running the app in the debugger will stop when the condition is reached.

Regards,
Ovanes