# When and Why to Use EXPECT_DEATH_IF_SUPPORTED Instead of ASSERT_DEATH in Cross‑Platform Tests

> Learn when and why to use EXPECT_DEATH_IF_SUPPORTED over ASSERT_DEATH for portable cross-platform tests. Avoid fatal test failures on unsupported platforms.

- Repository: [Google/googletest](https://github.com/google/googletest)
- Tags: best-practices
- Published: 2026-08-30

---

**Use `EXPECT_DEATH_IF_SUPPORTED` when writing portable death tests that must compile on platforms lacking death test support (such as Windows or embedded systems), while keeping the test execution non‑fatal, whereas `ASSERT_DEATH` requires death test support and aborts the test case on failure.**

Cross‑platform C++ testing with GoogleTest requires handling heterogeneous environments where death test capabilities vary. The `EXPECT_DEATH_IF_SUPPORTED` macro in [`googletest/include/gtest/gtest-death-test.h`](https://github.com/google/googletest/blob/main/googletest/include/gtest/gtest-death-test.h) provides a conditional alternative to `ASSERT_DEATH` that guarantees compilation success across all platforms while maintaining test coverage where possible.

## How EXPECT_DEATH_IF_SUPPORTED Works

The macro implements conditional compilation logic based on the `GTEST_HAS_DEATH_TEST` preprocessor definition. According to the GoogleTest source code in [`googletest/include/gtest/gtest-death-test.h`](https://github.com/google/googletest/blob/main/googletest/include/gtest/gtest-death-test.h) (lines 31–41), when death tests are available, the macro expands to the standard death test behavior. When disabled, it expands to a no‑op that still compiles the statement for syntax checking but issues a compile‑time warning instead of executing the test.

### Conditional Compilation Without #ifdef Blocks

Unlike raw `ASSERT_DEATH`, which causes compilation errors on unsupported platforms, `EXPECT_DEATH_IF_SUPPORTED` eliminates the need for `#ifdef GTEST_HAS_DEATH_TEST` guards throughout your test code. The macro automatically handles platform detection, allowing you to maintain a single source file for tests targeting both death‑test‑enabled and death‑test‑disabled environments.

## Key Differences: EXPECT_DEATH_IF_SUPPORTED vs ASSERT_DEATH

Understanding the semantic and platform differences between these macros ensures you select the appropriate assertion type for your cross‑platform test suite.

### Platform Support Requirements

**`ASSERT_DEATH`** requires that the platform defines `GTEST_HAS_DEATH_TEST`. On platforms where this macro is undefined—such as certain Windows environments or embedded systems—using `ASSERT_DEATH` results in a compilation failure.

**`EXPECT_DEATH_IF_SUPPORTED`** compiles successfully on all platforms. It performs the actual death test only when `GTEST_HAS_DEATH_TEST` is defined, otherwise generating a warning while allowing the test binary to build and run.

### Fatal vs Non‑Fatal Semantics

**`EXPECT_DEATH_IF_SUPPORTED`** implements non‑fatal expectations. If the death test fails or is skipped due to platform limitations, the test case continues execution. This behavior is critical when combining death‑test verification with subsequent state checks.

**`ASSERT_DEATH`** implements fatal semantics. A failure aborts the current test case immediately, preventing subsequent assertions from running. While `ASSERT_DEATH_IF_SUPPORTED` exists for fatal semantics with platform fallback, the standard `ASSERT_DEATH` lacks the platform compatibility layer.

## When to Use EXPECT_DEATH_IF_SUPPORTED

Prefer `EXPECT_DEATH_IF_SUPPORTED` (or `ASSERT_DEATH_IF_SUPPORTED` when fatal checks are required) in the following scenarios:

1. **Writing portable test code** that must compile on both death‑test‑enabled and death‑test‑disabled platforms without conditional compilation directives.
2. **Combining death‑test checks with other expectations** in the same test case, where you require the test to continue regardless of whether the death test executes.
3. **Maintaining single source files** for test suites rather than creating platform‑specific branches or sprinkling `#ifdef` blocks throughout the code.

## Implementation Details in GoogleTest

The macro definition resides in [`googletest/include/gtest/gtest-death-test.h`](https://github.com/google/googletest/blob/main/googletest/include/gtest/gtest-death-test.h). When `GTEST_HAS_DEATH_TEST` is defined, the implementation forwards to the standard death test macros. Otherwise, as documented in [`docs/reference/assertions.md`](https://github.com/google/googletest/blob/main/docs/reference/assertions.md) (lines 89–95), it expands to a helper that validates the statement's syntax at compile time while ensuring the code never executes at runtime.

Test coverage demonstrating these patterns appears in `googletest/test/gtest-death-test-test.cc` (lines 1319–1406), which exercises both supported and unsupported platform scenarios.

## Cross‑Platform Test Examples

The following examples demonstrate proper usage patterns for portable death tests.

### Non‑Fatal Death Test with Fallback

This example shows a test that verifies normal operation before attempting a death test, ensuring the suite continues even if death tests are unsupported:

```cpp
TEST(MyFeature, HandlesInvalidInput) {
  // Normal assertions that must always run.
  EXPECT_EQ(ProcessInput(0), 0);
  EXPECT_TRUE(CheckState());

  // Death test is only run where supported; otherwise only a warning is emitted.
  EXPECT_DEATH_IF_SUPPORTED(
      ProcessInput(-1),   // statement that should abort
      "Invalid input");   // regex matcher for the error message
}

```

### Fatal Death Test with Platform Support

Use `ASSERT_DEATH_IF_SUPPORTED` when a fatal assertion is required, aborting the test if the process does not die (on supported platforms):

```cpp
TEST(MyFeature, FatalInvalidInput) {
  // A fatal death test ensures the test stops if the process does not die.
  ASSERT_DEATH_IF_SUPPORTED(
      ProcessInput(-1),
      "Invalid input");
}

```

In the first example, the test suite continues after the death‑test check to verify additional object properties. In the second example, the fatal version aborts immediately on failure, mirroring standard `ASSERT_DEATH` behavior but with cross‑platform compilation safety.

## Summary

- **`EXPECT_DEATH_IF_SUPPORTED`** compiles on all platforms but only executes death tests when `GTEST_HAS_DEATH_TEST` is defined, issuing warnings otherwise.
- The macro eliminates the need for `#ifdef` guards while maintaining syntax validation of the test statement.
- **Non‑fatal semantics** allow test execution to continue after death‑test failures or platform skips, unlike the fatal `ASSERT_DEATH`.
- Use **`ASSERT_DEATH_IF_SUPPORTED`** when you require fatal semantics combined with cross‑platform compatibility.
- Implementation resides in [`googletest/include/gtest/gtest-death-test.h`](https://github.com/google/googletest/blob/main/googletest/include/gtest/gtest-death-test.h) (lines 31–41) with documentation in [`docs/reference/assertions.md`](https://github.com/google/googletest/blob/main/docs/reference/assertions.md).

## Frequently Asked Questions

### What happens when I use EXPECT_DEATH_IF_SUPPORTED on a platform without death test support?

The macro expands to a no‑op that compiles the statement argument for syntax verification but never executes it at runtime. According to the GoogleTest source code, this generates a compile‑time warning indicating that death tests are not supported on the current platform, while allowing the test binary to build and run successfully.

### What is the difference between EXPECT_DEATH_IF_SUPPORTED and ASSERT_DEATH_IF_SUPPORTED?

**`EXPECT_DEATH_IF_SUPPORTED`** is non‑fatal, meaning the test case continues execution even if the death test fails or is skipped. **`ASSERT_DEATH_IF_SUPPORTED`** is fatal, aborting the current test case immediately when the death test fails or cannot run, equivalent to standard `ASSERT_DEATH` behavior on supported platforms.

### Why should I use EXPECT_DEATH_IF_SUPPORTED instead of wrapping code in #ifdef GTEST_HAS_DEATH_TEST?

Using the macro produces cleaner, more maintainable code by centralizing the platform detection logic within the GoogleTest framework. It ensures consistent syntax validation across all platforms while reducing the risk of conditional compilation errors and eliminating visual clutter from preprocessor directives in your test files.

### Does EXPECT_DEATH_IF_SUPPORTED validate the statement syntax on unsupported platforms?

Yes. Even when `GTEST_HAS_DEATH_TEST` is undefined, the macro expands to a construct that compiles the statement argument, ensuring syntax errors are caught at compile time despite the code never executing at runtime. This provides safety without requiring separate compilation paths.