# GoogleTest Death Test Styles: Threadsafe vs Fast

> Explore GoogleTest death test styles threadsafe vs fast. Understand how to choose the right style for your project and optimize your tests.

- Repository: [Google/googletest](https://github.com/google/googletest)
- Tags: deep-dive
- Published: 2026-09-01

---

**GoogleTest provides two death test styles—`threadsafe` and `fast`—that control how child processes spawn to verify fatal assertions, trading binary re-execution overhead for multithreading safety.**

Death tests verify that code terminates correctly via `ASSERT_DEATH` or `EXPECT_DEATH`. According to the `google/googletest` source code, the framework implements two distinct execution models controlled by the `--gtest_death_test_style` flag, each optimized for different testing environments.

## Understanding Death Test Styles in GoogleTest

Death tests require spawning a child process to isolate fatal failures. The `gtest-death-test.cc` implementation provides two strategies for creating these child processes, with fundamentally different approaches to process initialization.

### The Threadsafe Style

The **`threadsafe`** style re-executes the test binary from the beginning. In `googletest/src/gtest-death-test.cc`, this implementation ensures the child process runs **only the specific death test** after relaunching.

This approach guarantees the child runs **single-threaded**, avoiding the well-known problems of `fork()` in multithreaded parents. Since the binary restarts cleanly, it does not inherit threads, locks, or memory state from the parent process.

The trade-off is performance. Because the entire binary initializes for each death test, this style incurs significant overhead when many death tests exist.

### The Fast Style

The **`fast`** style creates the child process **immediately after forking** (or cloning on Linux) and runs the death-test statement right away. According to the source in `gtest-death-test.cc`, this method continues execution from the current parent state.

While significantly faster—requiring only a fork/clone without binary re-initialization—this style is **not thread-safe**. If the parent process already contains active threads, the forked child inherits them, potentially causing deadlocks or undefined behavior when those threads held locks or operated in non-async-signal-safe code paths.

## Technical Implementation and Default Configuration

The default style is defined in `googletest/src/gtest-death-test.cc` at lines 99-103 as `GTEST_DEFAULT_DEATH_TEST_STYLE`, normally set to `"fast"`. However, Google's internal builds typically override this default to `"threadsafe"` for maximum safety.

The flag parsing occurs in `googletest/src/gtest.cc` (lines 6776-6829), where `GTEST_FLAG_SET` and `GTEST_FLAG_GET` macros manage the `death_test_style` value. The internal helper `InDeathTestChild()` in `gtest-death-test.cc` (lines 164-168) inspects this flag to determine if the current process is a death-test child.

Documentation in [`docs/advanced.md`](https://github.com/google/googletest/blob/main/docs/advanced.md) (lines 66-100) explains that forking multithreaded processes is unsafe because threads may hold locks or perform non-async-signal-safe operations, making the `threadsafe` style essential for multithreaded test binaries.

## Configuring Death Test Styles in Your Tests

Control death test execution globally or per-test using the `GTEST_FLAG_SET` macro.

Set the style globally in `main()` to affect all death tests:

```cpp
#include <gtest/gtest.h>

int main(int argc, char** argv) {
  testing::InitGoogleTest(&argc, argv);
  // Choose "threadsafe" for maximum safety, or "fast" for speed
  GTEST_FLAG_SET(death_test_style, "threadsafe");
  return RUN_ALL_TESTS();
}

```

Override the style for individual tests:

```cpp
TEST(MyDeathTest, ThreadSafeVerification) {
  GTEST_FLAG_SET(death_test_style, "threadsafe");
  ASSERT_DEATH(MyFunctionThatShouldAbort(), ".*");
}

TEST(MyDeathTest, FastVerification) {
  GTEST_FLAG_SET(death_test_style, "fast");
  ASSERT_DEATH(MyFunctionThatShouldAbort(), ".*");
}

```

Alternatively, use the command-line flag:

```bash
./my_test --gtest_death_test_style=threadsafe

```

## Summary

- **`threadsafe`** style re-executes the binary for each death test, ensuring single-threaded execution at the cost of slower startup.
- **`fast`** style uses `fork()` for immediate child creation, offering better performance but risking deadlocks in multithreaded parents.
- The default is `"fast"` in open-source GoogleTest, but `"threadsafe"` in Google's internal builds.
- Use `GTEST_FLAG_SET(death_test_style, "threadsafe")` when testing multithreaded code or when thread safety is paramount.
- Reference `googletest/src/gtest-death-test.cc` for the core implementation and [`docs/advanced.md`](https://github.com/google/googletest/blob/main/docs/advanced.md) for usage guidelines.

## Frequently Asked Questions

### What is the default death test style in GoogleTest?

The default style is defined in `googletest/src/gtest-death-test.cc` as `GTEST_DEFAULT_DEATH_TEST_STYLE`, which defaults to `"fast"` in the open-source release. However, Google's internal builds typically change this default to `"threadsafe"` to prioritize safety over performance.

### When should I use the threadsafe style over fast?

Use the **threadsafe** style when your test binary creates threads before running death tests, or when you cannot guarantee single-threaded execution. The `fast` style risks deadlocks if the parent process holds locks or operates in non-async-signal-safe states during the fork operation.

### How much performance difference exists between the two styles?

The **fast** style requires only a system `fork()` or `clone()`, while the **threadsafe** style re-executes the entire binary from `main()`. For binaries with heavy static initialization or many death tests, the threadsafe style significantly increases test duration, whereas fast style adds minimal per-test overhead.

### Can I mix death test styles within the same test binary?

Yes. You can set the global default via command-line flags or `main()`, then override individual tests using `GTEST_FLAG_SET(death_test_style, "threadsafe")` or `GTEST_FLAG_SET(death_test_style, "fast")` within specific `TEST` blocks. This allows critical multithreaded tests to use threadsafe mode while keeping single-threaded tests fast.