| `ASSERT_NEAR(val1, val2, abs_error);` | `EXPECT_NEAR(val1, val2, abs_error);` | the difference between `val1` and `val2` doesn't exceed the given absolute error |
#### Floating-Point Predicate-Format Functions
#### Floating-Point Predicate-Format Functions
Some floating-point operations are useful, but not that often used. In order to
Some floating-point operations are useful, but not that often used. In order to
avoid an explosion of new macros, we provide them as predicate-format functions
avoid an explosion of new macros, we provide them as predicate-format functions
that can be used in predicate assertion macros (e.g. `EXPECT_PRED_FORMAT2`,
that can be used in the predicate assertion macro
etc).
[`EXPECT_PRED_FORMAT2`](reference/assertions.md#EXPECT_PRED_FORMAT), for
example:
```c++
```c++
EXPECT_PRED_FORMAT2(testing::FloatLE,val1,val2);
EXPECT_PRED_FORMAT2(testing::FloatLE,val1,val2);
EXPECT_PRED_FORMAT2(testing::DoubleLE,val1,val2);
EXPECT_PRED_FORMAT2(testing::DoubleLE,val1,val2);
```
```
Verifies that `val1` is less than, or almost equal to, `val2`. You can replace
The above code verifies that `val1` is less than, or approximately equal to,
`EXPECT_PRED_FORMAT2` in the above table with `ASSERT_PRED_FORMAT2`.
`val2`.
### Asserting Using gMock Matchers
### Asserting Using gMock Matchers
gMock comes with a library of *matchers* for validating arguments passed to mock
See [`EXPECT_THAT`](reference/assertions.md#EXPECT_THAT) in the Assertions
objects. A gMock matcher is basically a predicate that knows how to describe
`ASSERT_DEATH(statement, matcher);` | `EXPECT_DEATH(statement, matcher);` | `statement` crashes with the given error
`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_DEBUG_DEATH(statement, matcher);` | `EXPECT_DEBUG_DEATH(statement, matcher);` | `statement` crashes with the given error **in debug mode**. When not in debug (i.e. `NDEBUG` is defined), this just executes `statement`
`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,
`predicate` is a function or function object that evaluates an integer exit
status, and `matcher` is either a gMock matcher matching a `const std::string&`
or a (Perl) regular expression - either of which is matched against the stderr
output of `statement`. For legacy reasons, a bare string (i.e. with no matcher)
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
`EXPECT` variants do not.
{: .callout .note}
> NOTE: We use the word "crash" here to mean that the process terminates with a
> *non-zero* exit status code. There are two possibilities: either the process
> has called `exit()` or `_exit()` with a non-zero value, or it may be killed by
> a signal.
>
> This means that if *`statement`* terminates the process with a 0 exit code, it
> is *not* considered a crash by `EXPECT_DEATH`. Use `EXPECT_EXIT` instead if
> this is the case, or if you want to restrict the exit code more precisely.
A predicate here must accept an `int` and return a `bool`. The death test
succeeds only if the predicate returns `true`. googletest defines a few
predicates that handle the most common cases:
```c++
To write a death test, simply use one of the macros inside your test function.
::testing::ExitedWithCode(exit_code)
For example,
```
This expression is `true` if the program exited normally with the given exit
code.
```c++
testing::KilledBySignal(signal_number)// Not available on Windows.
```
This expression is `true` if the program was killed by the given signal.
The `*_DEATH` macros are convenient wrappers for `*_EXIT` that use a predicate
that verifies the process' exit code is non-zero.
Note that a death test only cares about three things:
1. does `statement` abort or exit the process?
2. (in the case of `ASSERT_EXIT` and `EXPECT_EXIT`) does the exit status
satisfy `predicate`? Or (in the case of `ASSERT_DEATH` and `EXPECT_DEATH`)
is the exit status non-zero? And
3. does the stderr output match `matcher`?
In particular, if `statement` generates an `ASSERT_*` or `EXPECT_*` failure, it
will **not** cause the death test to fail, as googletest assertions don't abort
the process.
To write a death test, simply use one of the above macros inside your test
