views:

222

answers:

2

I saw the documentation of that feature is seem pretty major since it's in Google Test overview features and detailed in: http://code.google.com/p/googletest/wiki/AdvancedGuide#Death_Tests

They look like standard assert() but they're part of Google Test, so a xUnit testing framework. Therefor I wonder the real usage or advantage of using those death tests.

+1  A: 

The assertion is there to confirm that a function would bring about program termination if it were executed in the current process (the details explains that the death test is invoked from a subprocess which allows the tests to continue despite the death). This is useful because some code may guarantee program termination / abortion on failure (e.g. if there was an irrecoverable error), and unit tests should confirm that a function adheres to its documented behavior, regardless of what that might be.

The description on the wiki page really explains it best:

In many applications, there are assertions that can cause application failure if a condition is not met. These sanity checks, which ensure that the program is in a known good state, are there to fail at the earliest possible time after some program state is corrupted. If the assertion checks the wrong condition, then the program may proceed in an erroneous state, which could lead to memory corruption, security holes, or worse. Hence it is vitally important to test that such assertion statements work as expected.

Michael Aaron Safyan
The part that troubles me is the gain of using Google Death Tests over `ASSERT()` or `assert()`.
Wernight
@Wernight: If you use `assert` and it fails, then the process stops, and thus the unit test stops, no report is generated etc. By launching the test in another process, it's possible to monitor that it stopped as expected, report if it didn't, etc...
Matthieu M.
@Matthieu: So by replacing in the application traditional `assert()` by Google Test's `ASSERT_EXIT()` the release will work the same but during test execution assertions can correctly be checked.
Wernight
@Wernight: no, `ASSERT_EXIT` is a kind of Google Test. You use it in your test code. It means, "test that the specified code exits", just as `ASSERT_THROW` means, "test that the specified code throws". Leave the code under test alone.
Steve Jessop
@Steve: D'OH! Understood. Death Tests are test assertions to put in unit test code, just like `ASSERT_EQ`, that check that the program exists or crashes in a certain manner given some inputs. So in the program code we still use `assert()` or other traditional methods to close/crash the application.
Wernight
@Wernight: That's the bunny.
Steve Jessop
+1  A: 

I thought the introduction in your link explained it fairly well:

In many applications, there are assertions that can cause application failure if a condition is not met. These sanity checks, which ensure that the program is in a known good state, are there to fail at the earliest possible time after some program state is corrupted. If the assertion checks the wrong condition, then the program may proceed in an erroneous state, which could lead to memory corruption, security holes, or worse. Hence it is vitally important to test that such assertion statements work as expected.

Since these precondition checks cause the processes to die, we call such tests death tests. More generally, any test that checks that a program terminates in an expected fashion is also a death test.

What bit of that doesn't make sense?

Jon Cage
I probably missed that part. So the traditional `ASSERT()` is a death test.
Wernight
@Wernight: no, ASSERT_DEATH is a death test. A traditional `assert` is program behaviour for which you might like to write a death test, to prove that the process in which the `assert` occurs dies as expected.
Steve Jessop