I'm using Boost 1.35 and I notice that when a unit test aborts due to asserts in the code, it doesn't count as a failure -- the end report says "*** No errors detected" when in fact a call to abort() was made due to a failed assert. I'm thinking this would be a bug, but I'd like to ask first whether this is intended behavior before thinking it's a bug with Boost.Test. Have a good day! -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
on Mon Dec 08 2008, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
I'm using Boost 1.35 and I notice that when a unit test aborts due to asserts in the code, it doesn't count as a failure -- the end report says "*** No errors detected" when in fact a call to abort() was made due to a failed assert.
I'm thinking this would be a bug, but I'd like to ask first whether this is intended behavior before thinking it's a bug with Boost.Test.
Hi Mikhail, Since nobody has replied, would you open a Trac ticket? Otherwise, this important issue might get lost. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dean Michael Berris wrote:
I'm using Boost 1.35 and I notice that when a unit test aborts due to asserts in the code, it doesn't count as a failure -- the end report says "*** No errors detected" when in fact a call to abort() was made due to a failed assert.
I'm thinking this would be a bug, but I'd like to ask first whether this is intended behavior before thinking it's a bug with Boost.Test.
I believe this was fixed in 1.36.0 Gennadiy
On Fri, Dec 19, 2008 at 8:47 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Dean Michael Berris wrote:
I'm using Boost 1.35 and I notice that when a unit test aborts due to asserts in the code, it doesn't count as a failure -- the end report says "*** No errors detected" when in fact a call to abort() was made due to a failed assert.
I'm thinking this would be a bug, but I'd like to ask first whether this is intended behavior before thinking it's a bug with Boost.Test.
I believe this was fixed in 1.36.0
Would there be a patch that would fix this for 1.35.0? If not, where should I be looking to get this fixed in 1.35.0? Because upgrading to 1.36 (or anything higher for that matter) is not an option for me at the moment. Thanks. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
Would there be a patch that would fix this for 1.35.0? If not, where should I be looking to get this fixed in 1.35.0? Because upgrading to 1.36 (or anything higher for that matter) is not an option for me at the moment.
Thanks.
Not sure. It might've been fixed in patches applied December 14 2005. Gennadiy
On Sat, Dec 27, 2008 at 4:20 AM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
Would there be a patch that would fix this for 1.35.0? If not, where should I be looking to get this fixed in 1.35.0? Because upgrading to 1.36 (or anything higher for that matter) is not an option for me at the moment.
Thanks.
Not sure. It might've been fixed in patches applied December 14 2005.
Unfortunately, in another project I'm working on that uses Boost 1.36, I still see the problem manifesting itself. This should be simple to test: #define BOOST_AUTO_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE( assert_test ) { assert(false && !"Induced failure."); BOOST_CHECK(true); } The expected behavior is that once the test case asserts, an error should be detected due to abnormal program termination (on a call to std::abort). I should say that this occurs in Linux with GCC 4.3.2. HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
participants (3)
-
David Abrahams -
Dean Michael Berris -
Gennadiy Rozental