need ASSERT_NO_FATAL_FAILURE for propagating fatal failures

[GoogleCodeExporter]

Google Test doesn't depend on exceptions, so the ASSERT_* macros will
return from the current function when they failed.  This is all right
normally.  However, if your test calls a sub-routine that has an
ASSERT_* failure in it, your test will continue after the sub-routine
returns.  This may not be what you want.

To solve this, you can write

 Foo();  // This may generate an ASSERT_* failure.
 if (HasFatalFailure()) return;

where HasFatalFailure() is a static method of Google Test's
testing::Test class.  However this doesn't tell you which sub-routine
caused the problem when you call multiple of them in the same test.

After discussions with Googlers Bob Sidebotham and Matt Frantz, I'd
like to propose the following macro (the idea is mostly theirs):

 ASSERT_NO_FATAL_FAILURE(statement);

will execute 'statement' and assert that it doesn't generate any *new*
ASSERT_* failures.  If it does, Google Test will print a failure
message with the source text of 'statement' in it, and return from the
current function.

Normally you'll use ASSERT_NO_FATAL_FAILURE() when the inner-statement
is a call to a sub-routine.

For consistency, we'll also add an EXPECT_NO_FATAL_FAILURE(statement)
to match.

Original issue reported on code.google.com by shiq...@gmail.com on 5 Aug 2008 at 7:24

[GoogleCodeExporter]

I don't know why haven't hit this before, or why I wasn't paying more attention
during the original discussion, but this seems *extremely* unintuitive. Why 
isn't
this the *default* behavior? When I write an "ASSERT_()" I want it to behavie 
like
"assert()" might, but limited only to the test case. What are the implementation
challenges to making this happen? I'd much rather have a 
"IGNORE_FATAL_FAILURES()"
macro than the proposed macro pattern.

Again, apologies for not bringing this up during the initial discussion, or 
missing
it if it was already addressed.
-Chandler

Original comment by chandl...@gmail.com on 5 Aug 2008 at 7:35

[GoogleCodeExporter]

Chandler, the problem is that gtest needs to compile where exceptions are 
turned off,
which rules out throw.  long-jump is not an option either as its behavior is
undefined in a C++ program where objects can have non-trivial destructors.

Original comment by shiq...@gmail.com on 5 Aug 2008 at 8:02

[GoogleCodeExporter]

I suppose an alternative might be to always fork (on *NIX platforms, anyway) 
before
running a test, as in death tests, implementing ASSERT* using process death. 
That
would cleanly deliver Chandler's desired semantics, I think. Is this too 
expensive?

Bob

Original comment by Bob.Side...@gmail.com on 5 Aug 2008 at 8:13

[GoogleCodeExporter]

fork() is too heavy-handed as it changes the behavior of existing tests when 
they
have side effects.  We also don't want Google Test's behavior to diverage on
different platforms.

Note that death tests come with some caveats.  In particular, fork() doesn't 
work
well with threads, and thus cannot be used in the general test runner.  fork() 
also
makes debugging much harder as now the users need to deal with multiple 
processes.

Original comment by shiq...@gmail.com on 5 Aug 2008 at 8:21

[GoogleCodeExporter]

Original comment by shiq...@gmail.com on 30 Sep 2008 at 4:13

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by markus.h...@gmail.com on 30 Sep 2008 at 4:52

[GoogleCodeExporter]

Done in trunk.

Original comment by shiq...@gmail.com on 12 Oct 2008 at 3:22

• Changed state: Fixed