Robert Ramey:
I've traced through the code with the gdb and seems to me that when assert is invoked, the program bails more or less immediatly without jumping back to the orginal main or invoking an exception that can be caught. This results in tests which provoke assertions as being marked "passed".
assert should in principle call abort(), which should return a failure exit code to the OS, so the test should fail...
Actually, this is unbelievable to me and I have to believe that I'm missing something really dumb. I also took a cursory look at Boost Test code and don't see any special provision made for assert.
Also I investigated BOOST_ASSERT. It looks to me that this code is not conditional upon NDEBUG not being defined - that is that the code included by BOOST_ASSERT would still appear in a release build. Again, I can't help but feel that I'm missing something really obvious.
BOOST_ASSERT works in three modes. By default, it maps to assert, and assert does obey NDEBUG. If BOOST_DISABLE_ASSERTS is defined, BOOST_ASSERT is compiled out. If BOOST_ENABLE_ASSERT_HANDLER is defined, failed asserts call a function that can be supplied by the user. So if your code uses BOOST_ASSERT, you can define a custom handler in your tests that prints a message and cause the test to fail. http://www.boost.org/libs/utility/assert.html