1# Assertions Reference 2 3This page lists the assertion macros provided by GoogleTest for verifying code 4behavior. To use them, add `#include <gtest/gtest.h>`. 5 6The majority of the macros listed below come as a pair with an `EXPECT_` variant 7and an `ASSERT_` variant. Upon failure, `EXPECT_` macros generate nonfatal 8failures and allow the current function to continue running, while `ASSERT_` 9macros generate fatal failures and abort the current function. 10 11All assertion macros support streaming a custom failure message into them with 12the `<<` operator, for example: 13 14```cpp 15EXPECT_TRUE(my_condition) << "My condition is not true"; 16``` 17 18Anything that can be streamed to an `ostream` can be streamed to an assertion 19macro—in particular, C strings and string objects. If a wide string (`wchar_t*`, 20`TCHAR*` in `UNICODE` mode on Windows, or `std::wstring`) is streamed to an 21assertion, it will be translated to UTF-8 when printed. 22 23## Explicit Success and Failure {#success-failure} 24 25The assertions in this section generate a success or failure directly instead of 26testing a value or expression. These are useful when control flow, rather than a 27Boolean expression, determines the test's success or failure, as shown by the 28following example: 29 30```c++ 31switch(expression) { 32 case 1: 33 ... some checks ... 34 case 2: 35 ... some other checks ... 36 default: 37 FAIL() << "We shouldn't get here."; 38} 39``` 40 41### SUCCEED {#SUCCEED} 42 43`SUCCEED()` 44 45Generates a success. This *does not* make the overall test succeed. A test is 46considered successful only if none of its assertions fail during its execution. 47 48The `SUCCEED` assertion is purely documentary and currently doesn't generate any 49user-visible output. However, we may add `SUCCEED` messages to GoogleTest output 50in the future. 51 52### FAIL {#FAIL} 53 54`FAIL()` 55 56Generates a fatal failure, which returns from the current function. 57 58Can only be used in functions that return `void`. See 59[Assertion Placement](../advanced.md#assertion-placement) for more information. 60 61### ADD_FAILURE {#ADD_FAILURE} 62 63`ADD_FAILURE()` 64 65Generates a nonfatal failure, which allows the current function to continue 66running. 67 68### ADD_FAILURE_AT {#ADD_FAILURE_AT} 69 70`ADD_FAILURE_AT(`*`file_path`*`,`*`line_number`*`)` 71 72Generates a nonfatal failure at the file and line number specified. 73 74## Generalized Assertion {#generalized} 75 76The following assertion allows [matchers](matchers.md) to be used to verify 77values. 78 79### EXPECT_THAT {#EXPECT_THAT} 80 81`EXPECT_THAT(`*`value`*`,`*`matcher`*`)` \ 82`ASSERT_THAT(`*`value`*`,`*`matcher`*`)` 83 84Verifies that *`value`* matches the [matcher](matchers.md) *`matcher`*. 85 86For example, the following code verifies that the string `value1` starts with 87`"Hello"`, `value2` matches a regular expression, and `value3` is between 5 and 8810: 89 90```cpp 91#include <gmock/gmock.h> 92 93using ::testing::AllOf; 94using ::testing::Gt; 95using ::testing::Lt; 96using ::testing::MatchesRegex; 97using ::testing::StartsWith; 98 99... 100EXPECT_THAT(value1, StartsWith("Hello")); 101EXPECT_THAT(value2, MatchesRegex("Line \\d+")); 102ASSERT_THAT(value3, AllOf(Gt(5), Lt(10))); 103``` 104 105Matchers enable assertions of this form to read like English and generate 106informative failure messages. For example, if the above assertion on `value1` 107fails, the resulting message will be similar to the following: 108 109``` 110Value of: value1 111 Actual: "Hi, world!" 112Expected: starts with "Hello" 113``` 114 115GoogleTest provides a built-in library of matchers—see the 116[Matchers Reference](matchers.md). It is also possible to write your own 117matchers—see [Writing New Matchers Quickly](../gmock_cook_book.md#NewMatchers). 118The use of matchers makes `EXPECT_THAT` a powerful, extensible assertion. 119 120*The idea for this assertion was borrowed from Joe Walnes' Hamcrest project, 121which adds `assertThat()` to JUnit.* 122 123## Boolean Conditions {#boolean} 124 125The following assertions test Boolean conditions. 126 127### EXPECT_TRUE {#EXPECT_TRUE} 128 129`EXPECT_TRUE(`*`condition`*`)` \ 130`ASSERT_TRUE(`*`condition`*`)` 131 132Verifies that *`condition`* is true. 133 134### EXPECT_FALSE {#EXPECT_FALSE} 135 136`EXPECT_FALSE(`*`condition`*`)` \ 137`ASSERT_FALSE(`*`condition`*`)` 138 139Verifies that *`condition`* is false. 140 141## Binary Comparison {#binary-comparison} 142 143The following assertions compare two values. The value arguments must be 144comparable by the assertion's comparison operator, otherwise a compiler error 145will result. 146 147If an argument supports the `<<` operator, it will be called to print the 148argument when the assertion fails. Otherwise, GoogleTest will attempt to print 149them in the best way it can—see 150[Teaching GoogleTest How to Print Your Values](../advanced.md#teaching-googletest-how-to-print-your-values). 151 152Arguments are always evaluated exactly once, so it's OK for the arguments to 153have side effects. However, the argument evaluation order is undefined and 154programs should not depend on any particular argument evaluation order. 155 156These assertions work with both narrow and wide string objects (`string` and 157`wstring`). 158 159See also the [Floating-Point Comparison](#floating-point) assertions to compare 160floating-point numbers and avoid problems caused by rounding. 161 162### EXPECT_EQ {#EXPECT_EQ} 163 164`EXPECT_EQ(`*`val1`*`,`*`val2`*`)` \ 165`ASSERT_EQ(`*`val1`*`,`*`val2`*`)` 166 167Verifies that *`val1`*`==`*`val2`*. 168 169Does pointer equality on pointers. If used on two C strings, it tests if they 170are in the same memory location, not if they have the same value. Use 171[`EXPECT_STREQ`](#EXPECT_STREQ) to compare C strings (e.g. `const char*`) by 172value. 173 174When comparing a pointer to `NULL`, use `EXPECT_EQ(`*`ptr`*`, nullptr)` instead 175of `EXPECT_EQ(`*`ptr`*`, NULL)`. 176 177### EXPECT_NE {#EXPECT_NE} 178 179`EXPECT_NE(`*`val1`*`,`*`val2`*`)` \ 180`ASSERT_NE(`*`val1`*`,`*`val2`*`)` 181 182Verifies that *`val1`*`!=`*`val2`*. 183 184Does pointer equality on pointers. If used on two C strings, it tests if they 185are in different memory locations, not if they have different values. Use 186[`EXPECT_STRNE`](#EXPECT_STRNE) to compare C strings (e.g. `const char*`) by 187value. 188 189When comparing a pointer to `NULL`, use `EXPECT_NE(`*`ptr`*`, nullptr)` instead 190of `EXPECT_NE(`*`ptr`*`, NULL)`. 191 192### EXPECT_LT {#EXPECT_LT} 193 194`EXPECT_LT(`*`val1`*`,`*`val2`*`)` \ 195`ASSERT_LT(`*`val1`*`,`*`val2`*`)` 196 197Verifies that *`val1`*`<`*`val2`*. 198 199### EXPECT_LE {#EXPECT_LE} 200 201`EXPECT_LE(`*`val1`*`,`*`val2`*`)` \ 202`ASSERT_LE(`*`val1`*`,`*`val2`*`)` 203 204Verifies that *`val1`*`<=`*`val2`*. 205 206### EXPECT_GT {#EXPECT_GT} 207 208`EXPECT_GT(`*`val1`*`,`*`val2`*`)` \ 209`ASSERT_GT(`*`val1`*`,`*`val2`*`)` 210 211Verifies that *`val1`*`>`*`val2`*. 212 213### EXPECT_GE {#EXPECT_GE} 214 215`EXPECT_GE(`*`val1`*`,`*`val2`*`)` \ 216`ASSERT_GE(`*`val1`*`,`*`val2`*`)` 217 218Verifies that *`val1`*`>=`*`val2`*. 219 220## String Comparison {#c-strings} 221 222The following assertions compare two **C strings**. To compare two `string` 223objects, use [`EXPECT_EQ`](#EXPECT_EQ) or [`EXPECT_NE`](#EXPECT_NE) instead. 224 225These assertions also accept wide C strings (`wchar_t*`). If a comparison of two 226wide strings fails, their values will be printed as UTF-8 narrow strings. 227 228To compare a C string with `NULL`, use `EXPECT_EQ(`*`c_string`*`, nullptr)` or 229`EXPECT_NE(`*`c_string`*`, nullptr)`. 230 231### EXPECT_STREQ {#EXPECT_STREQ} 232 233`EXPECT_STREQ(`*`str1`*`,`*`str2`*`)` \ 234`ASSERT_STREQ(`*`str1`*`,`*`str2`*`)` 235 236Verifies that the two C strings *`str1`* and *`str2`* have the same contents. 237 238### EXPECT_STRNE {#EXPECT_STRNE} 239 240`EXPECT_STRNE(`*`str1`*`,`*`str2`*`)` \ 241`ASSERT_STRNE(`*`str1`*`,`*`str2`*`)` 242 243Verifies that the two C strings *`str1`* and *`str2`* have different contents. 244 245### EXPECT_STRCASEEQ {#EXPECT_STRCASEEQ} 246 247`EXPECT_STRCASEEQ(`*`str1`*`,`*`str2`*`)` \ 248`ASSERT_STRCASEEQ(`*`str1`*`,`*`str2`*`)` 249 250Verifies that the two C strings *`str1`* and *`str2`* have the same contents, 251ignoring case. 252 253### EXPECT_STRCASENE {#EXPECT_STRCASENE} 254 255`EXPECT_STRCASENE(`*`str1`*`,`*`str2`*`)` \ 256`ASSERT_STRCASENE(`*`str1`*`,`*`str2`*`)` 257 258Verifies that the two C strings *`str1`* and *`str2`* have different contents, 259ignoring case. 260 261## Floating-Point Comparison {#floating-point} 262 263The following assertions compare two floating-point values. 264 265Due to rounding errors, it is very unlikely that two floating-point values will 266match exactly, so `EXPECT_EQ` is not suitable. In general, for floating-point 267comparison to make sense, the user needs to carefully choose the error bound. 268 269GoogleTest also provides assertions that use a default error bound based on 270Units in the Last Place (ULPs). To learn more about ULPs, see the article 271[Comparing Floating Point Numbers](https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/). 272 273### EXPECT_FLOAT_EQ {#EXPECT_FLOAT_EQ} 274 275`EXPECT_FLOAT_EQ(`*`val1`*`,`*`val2`*`)` \ 276`ASSERT_FLOAT_EQ(`*`val1`*`,`*`val2`*`)` 277 278Verifies that the two `float` values *`val1`* and *`val2`* are approximately 279equal, to within 4 ULPs from each other. Infinity and the largest finite float 280value are considered to be one ULP apart. 281 282### EXPECT_DOUBLE_EQ {#EXPECT_DOUBLE_EQ} 283 284`EXPECT_DOUBLE_EQ(`*`val1`*`,`*`val2`*`)` \ 285`ASSERT_DOUBLE_EQ(`*`val1`*`,`*`val2`*`)` 286 287Verifies that the two `double` values *`val1`* and *`val2`* are approximately 288equal, to within 4 ULPs from each other. Infinity and the largest finite double 289value are considered to be one ULP apart. 290 291### EXPECT_NEAR {#EXPECT_NEAR} 292 293`EXPECT_NEAR(`*`val1`*`,`*`val2`*`,`*`abs_error`*`)` \ 294`ASSERT_NEAR(`*`val1`*`,`*`val2`*`,`*`abs_error`*`)` 295 296Verifies that the difference between *`val1`* and *`val2`* does not exceed the 297absolute error bound *`abs_error`*. 298 299If *`val`* and *`val2`* are both infinity of the same sign, the difference is 300considered to be 0. Otherwise, if either value is infinity, the difference is 301considered to be infinity. All non-NaN values (including infinity) are 302considered to not exceed an *`abs_error`* of infinity. 303 304## Exception Assertions {#exceptions} 305 306The following assertions verify that a piece of code throws, or does not throw, 307an exception. Usage requires exceptions to be enabled in the build environment. 308 309Note that the piece of code under test can be a compound statement, for example: 310 311```cpp 312EXPECT_NO_THROW({ 313 int n = 5; 314 DoSomething(&n); 315}); 316``` 317 318### EXPECT_THROW {#EXPECT_THROW} 319 320`EXPECT_THROW(`*`statement`*`,`*`exception_type`*`)` \ 321`ASSERT_THROW(`*`statement`*`,`*`exception_type`*`)` 322 323Verifies that *`statement`* throws an exception of type *`exception_type`*. 324 325### EXPECT_ANY_THROW {#EXPECT_ANY_THROW} 326 327`EXPECT_ANY_THROW(`*`statement`*`)` \ 328`ASSERT_ANY_THROW(`*`statement`*`)` 329 330Verifies that *`statement`* throws an exception of any type. 331 332### EXPECT_NO_THROW {#EXPECT_NO_THROW} 333 334`EXPECT_NO_THROW(`*`statement`*`)` \ 335`ASSERT_NO_THROW(`*`statement`*`)` 336 337Verifies that *`statement`* does not throw any exception. 338 339## Predicate Assertions {#predicates} 340 341The following assertions enable more complex predicates to be verified while 342printing a more clear failure message than if `EXPECT_TRUE` were used alone. 343 344### EXPECT_PRED* {#EXPECT_PRED} 345 346`EXPECT_PRED1(`*`pred`*`,`*`val1`*`)` \ 347`EXPECT_PRED2(`*`pred`*`,`*`val1`*`,`*`val2`*`)` \ 348`EXPECT_PRED3(`*`pred`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`)` \ 349`EXPECT_PRED4(`*`pred`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`,`*`val4`*`)` \ 350`EXPECT_PRED5(`*`pred`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`,`*`val4`*`,`*`val5`*`)` 351 352`ASSERT_PRED1(`*`pred`*`,`*`val1`*`)` \ 353`ASSERT_PRED2(`*`pred`*`,`*`val1`*`,`*`val2`*`)` \ 354`ASSERT_PRED3(`*`pred`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`)` \ 355`ASSERT_PRED4(`*`pred`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`,`*`val4`*`)` \ 356`ASSERT_PRED5(`*`pred`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`,`*`val4`*`,`*`val5`*`)` 357 358Verifies that the predicate *`pred`* returns `true` when passed the given values 359as arguments. 360 361The parameter *`pred`* is a function or functor that accepts as many arguments 362as the corresponding macro accepts values. If *`pred`* returns `true` for the 363given arguments, the assertion succeeds, otherwise the assertion fails. 364 365When the assertion fails, it prints the value of each argument. Arguments are 366always evaluated exactly once. 367 368As an example, see the following code: 369 370```cpp 371// Returns true if m and n have no common divisors except 1. 372bool MutuallyPrime(int m, int n) { ... } 373... 374const int a = 3; 375const int b = 4; 376const int c = 10; 377... 378EXPECT_PRED2(MutuallyPrime, a, b); // Succeeds 379EXPECT_PRED2(MutuallyPrime, b, c); // Fails 380``` 381 382In the above example, the first assertion succeeds, and the second fails with 383the following message: 384 385``` 386MutuallyPrime(b, c) is false, where 387b is 4 388c is 10 389``` 390 391Note that if the given predicate is an overloaded function or a function 392template, the assertion macro might not be able to determine which version to 393use, and it might be necessary to explicitly specify the type of the function. 394For example, for a Boolean function `IsPositive()` overloaded to take either a 395single `int` or `double` argument, it would be necessary to write one of the 396following: 397 398```cpp 399EXPECT_PRED1(static_cast<bool (*)(int)>(IsPositive), 5); 400EXPECT_PRED1(static_cast<bool (*)(double)>(IsPositive), 3.14); 401``` 402 403Writing simply `EXPECT_PRED1(IsPositive, 5);` would result in a compiler error. 404Similarly, to use a template function, specify the template arguments: 405 406```cpp 407template <typename T> 408bool IsNegative(T x) { 409 return x < 0; 410} 411... 412EXPECT_PRED1(IsNegative<int>, -5); // Must specify type for IsNegative 413``` 414 415If a template has multiple parameters, wrap the predicate in parentheses so the 416macro arguments are parsed correctly: 417 418```cpp 419ASSERT_PRED2((MyPredicate<int, int>), 5, 0); 420``` 421 422### EXPECT_PRED_FORMAT* {#EXPECT_PRED_FORMAT} 423 424`EXPECT_PRED_FORMAT1(`*`pred_formatter`*`,`*`val1`*`)` \ 425`EXPECT_PRED_FORMAT2(`*`pred_formatter`*`,`*`val1`*`,`*`val2`*`)` \ 426`EXPECT_PRED_FORMAT3(`*`pred_formatter`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`)` \ 427`EXPECT_PRED_FORMAT4(`*`pred_formatter`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`,`*`val4`*`)` 428\ 429`EXPECT_PRED_FORMAT5(`*`pred_formatter`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`,`*`val4`*`,`*`val5`*`)` 430 431`ASSERT_PRED_FORMAT1(`*`pred_formatter`*`,`*`val1`*`)` \ 432`ASSERT_PRED_FORMAT2(`*`pred_formatter`*`,`*`val1`*`,`*`val2`*`)` \ 433`ASSERT_PRED_FORMAT3(`*`pred_formatter`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`)` \ 434`ASSERT_PRED_FORMAT4(`*`pred_formatter`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`,`*`val4`*`)` 435\ 436`ASSERT_PRED_FORMAT5(`*`pred_formatter`*`,`*`val1`*`,`*`val2`*`,`*`val3`*`,`*`val4`*`,`*`val5`*`)` 437 438Verifies that the predicate *`pred_formatter`* succeeds when passed the given 439values as arguments. 440 441The parameter *`pred_formatter`* is a *predicate-formatter*, which is a function 442or functor with the signature: 443 444```cpp 445testing::AssertionResult PredicateFormatter(const char* expr1, 446 const char* expr2, 447 ... 448 const char* exprn, 449 T1 val1, 450 T2 val2, 451 ... 452 Tn valn); 453``` 454 455where *`val1`*, *`val2`*, ..., *`valn`* are the values of the predicate 456arguments, and *`expr1`*, *`expr2`*, ..., *`exprn`* are the corresponding 457expressions as they appear in the source code. The types `T1`, `T2`, ..., `Tn` 458can be either value types or reference types; if an argument has type `T`, it 459can be declared as either `T` or `const T&`, whichever is appropriate. For more 460about the return type `testing::AssertionResult`, see 461[Using a Function That Returns an AssertionResult](../advanced.md#using-a-function-that-returns-an-assertionresult). 462 463As an example, see the following code: 464 465```cpp 466// Returns the smallest prime common divisor of m and n, 467// or 1 when m and n are mutually prime. 468int SmallestPrimeCommonDivisor(int m, int n) { ... } 469 470// Returns true if m and n have no common divisors except 1. 471bool MutuallyPrime(int m, int n) { ... } 472 473// A predicate-formatter for asserting that two integers are mutually prime. 474testing::AssertionResult AssertMutuallyPrime(const char* m_expr, 475 const char* n_expr, 476 int m, 477 int n) { 478 if (MutuallyPrime(m, n)) return testing::AssertionSuccess(); 479 480 return testing::AssertionFailure() << m_expr << " and " << n_expr 481 << " (" << m << " and " << n << ") are not mutually prime, " 482 << "as they have a common divisor " << SmallestPrimeCommonDivisor(m, n); 483} 484 485... 486const int a = 3; 487const int b = 4; 488const int c = 10; 489... 490EXPECT_PRED_FORMAT2(AssertMutuallyPrime, a, b); // Succeeds 491EXPECT_PRED_FORMAT2(AssertMutuallyPrime, b, c); // Fails 492``` 493 494In the above example, the final assertion fails and the predicate-formatter 495produces the following failure message: 496 497``` 498b and c (4 and 10) are not mutually prime, as they have a common divisor 2 499``` 500 501## Windows HRESULT Assertions {#HRESULT} 502 503The following assertions test for `HRESULT` success or failure. For example: 504 505```cpp 506CComPtr<IShellDispatch2> shell; 507ASSERT_HRESULT_SUCCEEDED(shell.CoCreateInstance(L"Shell.Application")); 508CComVariant empty; 509ASSERT_HRESULT_SUCCEEDED(shell->ShellExecute(CComBSTR(url), empty, empty, empty, empty)); 510``` 511 512The generated output contains the human-readable error message associated with 513the returned `HRESULT` code. 514 515### EXPECT_HRESULT_SUCCEEDED {#EXPECT_HRESULT_SUCCEEDED} 516 517`EXPECT_HRESULT_SUCCEEDED(`*`expression`*`)` \ 518`ASSERT_HRESULT_SUCCEEDED(`*`expression`*`)` 519 520Verifies that *`expression`* is a success `HRESULT`. 521 522### EXPECT_HRESULT_FAILED {#EXPECT_HRESULT_FAILED} 523 524`EXPECT_HRESULT_FAILED(`*`expression`*`)` \ 525`ASSERT_HRESULT_FAILED(`*`expression`*`)` 526 527Verifies that *`expression`* is a failure `HRESULT`. 528 529## Death Assertions {#death} 530 531The following assertions verify that a piece of code causes the process to 532terminate. For context, see [Death Tests](../advanced.md#death-tests). 533 534These assertions spawn a new process and execute the code under test in that 535process. How that happens depends on the platform and the variable 536`::testing::GTEST_FLAG(death_test_style)`, which is initialized from the 537command-line flag `--gtest_death_test_style`. 538 539* On POSIX systems, `fork()` (or `clone()` on Linux) is used to spawn the 540 child, after which: 541 * If the variable's value is `"fast"`, the death test statement is 542 immediately executed. 543 * If the variable's value is `"threadsafe"`, the child process re-executes 544 the unit test binary just as it was originally invoked, but with some 545 extra flags to cause just the single death test under consideration to 546 be run. 547* On Windows, the child is spawned using the `CreateProcess()` API, and 548 re-executes the binary to cause just the single death test under 549 consideration to be run - much like the `"threadsafe"` mode on POSIX. 550 551Other values for the variable are illegal and will cause the death test to fail. 552Currently, the flag's default value is 553**`"fast"`**. 554 555If the death test statement runs to completion without dying, the child process 556will nonetheless terminate, and the assertion fails. 557 558Note that the piece of code under test can be a compound statement, for example: 559 560```cpp 561EXPECT_DEATH({ 562 int n = 5; 563 DoSomething(&n); 564}, "Error on line .* of DoSomething()"); 565``` 566 567### EXPECT_DEATH {#EXPECT_DEATH} 568 569`EXPECT_DEATH(`*`statement`*`,`*`matcher`*`)` \ 570`ASSERT_DEATH(`*`statement`*`,`*`matcher`*`)` 571 572Verifies that *`statement`* causes the process to terminate with a nonzero exit 573status and produces `stderr` output that matches *`matcher`*. 574 575The parameter *`matcher`* is either a [matcher](matchers.md) for a `const 576std::string&`, or a regular expression (see 577[Regular Expression Syntax](../advanced.md#regular-expression-syntax))—a bare 578string *`s`* (with no matcher) is treated as 579[`ContainsRegex(s)`](matchers.md#string-matchers), **not** 580[`Eq(s)`](matchers.md#generic-comparison). 581 582For example, the following code verifies that calling `DoSomething(42)` causes 583the process to die with an error message that contains the text `My error`: 584 585```cpp 586EXPECT_DEATH(DoSomething(42), "My error"); 587``` 588 589### EXPECT_DEATH_IF_SUPPORTED {#EXPECT_DEATH_IF_SUPPORTED} 590 591`EXPECT_DEATH_IF_SUPPORTED(`*`statement`*`,`*`matcher`*`)` \ 592`ASSERT_DEATH_IF_SUPPORTED(`*`statement`*`,`*`matcher`*`)` 593 594If death tests are supported, behaves the same as 595[`EXPECT_DEATH`](#EXPECT_DEATH). Otherwise, verifies nothing. 596 597### EXPECT_DEBUG_DEATH {#EXPECT_DEBUG_DEATH} 598 599`EXPECT_DEBUG_DEATH(`*`statement`*`,`*`matcher`*`)` \ 600`ASSERT_DEBUG_DEATH(`*`statement`*`,`*`matcher`*`)` 601 602In debug mode, behaves the same as [`EXPECT_DEATH`](#EXPECT_DEATH). When not in 603debug mode (i.e. `NDEBUG` is defined), just executes *`statement`*. 604 605### EXPECT_EXIT {#EXPECT_EXIT} 606 607`EXPECT_EXIT(`*`statement`*`,`*`predicate`*`,`*`matcher`*`)` \ 608`ASSERT_EXIT(`*`statement`*`,`*`predicate`*`,`*`matcher`*`)` 609 610Verifies that *`statement`* causes the process to terminate with an exit status 611that satisfies *`predicate`*, and produces `stderr` output that matches 612*`matcher`*. 613 614The parameter *`predicate`* is a function or functor that accepts an `int` exit 615status and returns a `bool`. GoogleTest provides two predicates to handle common 616cases: 617 618```cpp 619// Returns true if the program exited normally with the given exit status code. 620::testing::ExitedWithCode(exit_code); 621 622// Returns true if the program was killed by the given signal. 623// Not available on Windows. 624::testing::KilledBySignal(signal_number); 625``` 626 627The parameter *`matcher`* is either a [matcher](matchers.md) for a `const 628std::string&`, or a regular expression (see 629[Regular Expression Syntax](../advanced.md#regular-expression-syntax))—a bare 630string *`s`* (with no matcher) is treated as 631[`ContainsRegex(s)`](matchers.md#string-matchers), **not** 632[`Eq(s)`](matchers.md#generic-comparison). 633 634For example, the following code verifies that calling `NormalExit()` causes the 635process to print a message containing the text `Success` to `stderr` and exit 636with exit status code 0: 637 638```cpp 639EXPECT_EXIT(NormalExit(), testing::ExitedWithCode(0), "Success"); 640``` 641