`ASSERT_DEATH(statement, regex);` | `EXPECT_DEATH(statement, regex);` | `statement` crashes with the given error
`ASSERT_DEATH(statement, matcher);` | `EXPECT_DEATH(statement, matcher);` | `statement` crashes with the given error
`ASSERT_DEATH_IF_SUPPORTED(statement, regex);` | `EXPECT_DEATH_IF_SUPPORTED(statement, regex);` | if death tests are supported, verifies that `statement` crashes with the given error; otherwise verifies nothing
`ASSERT_DEATH_IF_SUPPORTED(statement, matcher);` | `EXPECT_DEATH_IF_SUPPORTED(statement, matcher);` | if death tests are supported, verifies that `statement` crashes with the given error; otherwise verifies nothing
`ASSERT_EXIT(statement, predicate, regex);` | `EXPECT_EXIT(statement, predicate, regex);` | `statement` exits with the given error, and its exit code matches `predicate`
`ASSERT_EXIT(statement, predicate, matcher);` | `EXPECT_EXIT(statement, predicate, matcher);` | `statement` exits with the given error, and its exit code matches `predicate`
where `statement` is a statement that is expected to cause the process to die,
where `statement` is a statement that is expected to cause the process to die,
`predicate` is a function or function object that evaluates an integer exit
`predicate` is a function or function object that evaluates an integer exit
status, and `regex` is a (Perl) regular expression that the stderr output of
status, and `matcher` is either a GMock matcher matching a `const std::string&`
`statement` is expected to match. Note that `statement` can be *any valid
or a (Perl) regular expression - either of which is matched against the stderr
statement* (including *compound statement*) and doesn't have to be an
output of `statement`. For legacy reasons, a bare string (i.e. with no matcher)
expression.
is interpreted as `ContainsRegex(str)`, **not**`Eq(str)`. Note that `statement`
can be *any valid statement* (including *compound statement*) and doesn't have
to be an expression.
As usual, the `ASSERT` variants abort the current test function, while the
As usual, the `ASSERT` variants abort the current test function, while the
`EXPECT` variants do not.
`EXPECT` variants do not.
...
@@ -756,8 +741,8 @@ necessary.
...
@@ -756,8 +741,8 @@ necessary.
IMPORTANT: We strongly recommend you to follow the convention of naming your
IMPORTANT: We strongly recommend you to follow the convention of naming your
**test suite** (not test) `*DeathTest` when it contains a death test, as
**test suite** (not test) `*DeathTest` when it contains a death test, as
demonstrated in the above example. The[Death Tests And
For more details, see the comments at the definitions of these functions.
For more details, see the comments at the definitions of these functions.
NOTE: The `INSTANTIATE_TEST_SUITE_P` keyword is recommended (addressing https://github.com/google/googletest/issues/1085) For 1.8.1 and previous releases the keyword is `INSTANTIATE_TEST_CASE_P`. which has been deprecated in favor of INSTANTIATE_TEST_SUITE_P.
The following statement will instantiate tests from the `FooTest` test suite
each with parameter values `"meeny"`, `"miny"`, and `"moe"`.
The following statement will instantiate tests from the `FooTest` test suite each
with parameter values `"meeny"`, `"miny"`, and `"moe"`.
```c++
```c++
INSTANTIATE_TEST_SUITE_P(InstantiationName,
INSTANTIATE_TEST_SUITE_P(InstantiationName,
FooTest,
FooTest,
::testing::Values("meeny","miny","moe"));
testing::Values("meeny","miny","moe"));
```
```
NOTE: The code above must be placed at global or namespace scope, not at
NOTE: The code above must be placed at global or namespace scope, not at
...
@@ -1440,7 +1419,7 @@ parameter values `"cat"` and `"dog"`:
...
@@ -1440,7 +1419,7 @@ parameter values `"cat"` and `"dog"`:
[should not contain underscores](https://github.com/google/googletest/blob/master/googletest/docs/faq.md#why-should-test-suite-names-and-test-names-not-contain-underscore)
