Hi Thorsten, While the test makes no sense it is often desirable to run all of the other tests and simply mark this failure. If the behaviour were to hang in the debugger this would not work well for the automated builds although it would be convenient for us developers when debugging. I am normally compiling directly with Visual Studio, but this is not an issue. You can start an executable under the debugger anyhow. If this is inconvenient then you will need to find an alternative means for switching the assertion behaviour, such as a command-line switch. I think this was added to the unit test framework in version 1.30.2 as --catch_system_errors="no". Otherwise there is the environment variable BOOST_TEST_CATCH_SYSTEM_ERRORS which does the same job. The reason the unit tests do not crash and exhibit the default just-in-time debugger behaviour is because of the unit test program execution monitor. The code that effects this is in boost/test/impl/execution_monitor.ipp. You will notice that there is code in execution_monitor::execute to configure the catch_system_errors flag to false if a debugger is already attached. Since this doesn't do quite what you want, you will probably need to modify the _set_se_translator behaviour. The simplest thing to do would probably be to turn off the SEH translator by avoiding the call while you are debugging. Best Wishes, Neil Groves -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen Sent: 09 December 2007 16:40 To: boost@lists.boost.org Subject: Re: [boost] [test] integration with debugger Neil Groves skrev:
Hi Thorsten,
I normally place soft breakpoint in the code that announces the test failure and walk the call stack.
You are compiling directly with visual studio then? I'm usign bjam + slickedit as my enviroenment.
Alternatively you can use the IsDebuggerPresent() call combined with DebugBreak as a Windows only modification to the assertions. This only causes a debug break if a developer has attached a local debugger. The automated unit test execution is unaffected.
I would prefer if the the unit-test itself could be debugged. The unite-test makes no sense if there is a serious assertion triggering somewhere.
I'm a bit annoyed that I don't break into the debugger, when an assertion triggers.
When I write a normal program, it crashes and allows me to debug it...with boost.test, the behavior has been modified somehow. -Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost