# How to Use SetUpTestSuite and TearDownTestSuite in Google Test for One-Time Initialization > Master SetUpTestSuite and TearDownTestSuite in Google Test for efficient one-time test suite initialization and cleanup. Optimize shared resource management. - Repository: [Google/googletest](https://github.com/google/googletest) - Tags: how-to-guide - Published: 2026-08-31 --- **SetUpTestSuite and TearDownTestSuite are static callback methods that execute exactly once before the first test and after the last test in a Google Test suite, enabling efficient shared resource management without per-test overhead.** The `google/googletest` framework organizes related tests into suites using fixture classes. While `SetUp()` and `TearDown()` handle per-test initialization, the static `SetUpTestSuite` and `TearDownTestSuite` methods provide a mechanism for expensive one-time setup and cleanup that persists across all tests sharing the same fixture, reducing runtime overhead for heavy resources like database connections or file handles. ## What Are SetUpTestSuite and TearDownTestSuite? Google Test provides two static hooks that fixture classes can override to manage **suite-level lifecycle events**: - **`static void SetUpTestSuite()`** – Invoked once before the first test in the suite begins execution. - **`static void TearDownTestSuite()`** – Invoked once after the last test in the suite completes execution. These methods are declared as `static` because the framework invokes them **without instantiating the test fixture class**. This design allows you to initialize shared state before any test object exists and clean up after all test objects have been destroyed. ## How Suite-Level Setup Works Internally The Google Test framework stores function pointers to your callbacks and executes them at the appropriate lifecycle boundaries. ### Function Pointer Storage In [`googletest/include/gtest/gtest.h`](https://github.com/google/googletest/blob/main/googletest/include/gtest/gtest.h), the `TestSuite` class maintains internal pointers to the user-provided functions: ```cpp // Internal storage of callbacks SetUpTestSuiteFunc set_up_tc_; TearDownTestSuiteFunc tear_down_tc_; ``` The type aliases for these callbacks are defined in [`googletest/include/gtest/internal/gtest-internal.h`](https://github.com/google/googletest/blob/main/googletest/include/gtest/internal/gtest-internal.h) as `void (*)()` function pointers. ### Execution Flow When the test runner executes a suite, it triggers the callbacks through dedicated runner methods: 1. `TestSuite::RunSetUpTestSuite()` executes the stored `set_up_tc_` pointer before the first `TEST_F` 2. All individual tests in the suite execute sequentially 3. `TestSuite::RunTearDownTestSuite()` executes the stored `tear_down_tc_` pointer after the final test finishes The registration of these callbacks occurs during test fixture compilation via mechanisms defined in [`googletest/src/gtest-internal-inl.h`](https://github.com/google/googletest/blob/main/googletest/src/gtest-internal-inl.h), ensuring the framework correctly associates the static methods with their respective test suites. ## Practical Implementation Example Below is a complete implementation demonstrating shared database connection management across multiple tests: ```cpp // my_test.cc #include class DatabaseTest : public ::testing::Test { protected: // Called once before any DatabaseTest runs. static void SetUpTestSuite() { // Expensive set-up that is shared by all tests. db_ = new DatabaseConnection("test_db"); ASSERT_TRUE(db_->Open()); } // Called once after the last DatabaseTest finishes. static void TearDownTestSuite() { // Clean up the shared resource. db_->Close(); delete db_; db_ = nullptr; } // Per-test set-up/tear-down (runs before/after each TEST_F). void SetUp() override { /*…*/ } void TearDown() override { /*…*/ } // Shared pointer accessed by each test. static DatabaseConnection* db_; }; DatabaseConnection* DatabaseTest::db_ = nullptr; // Individual tests can use the shared connection. TEST_F(DatabaseTest, Insert) { EXPECT_TRUE(db_->InsertRecord("key", "value")); } TEST_F(DatabaseTest, Query) { EXPECT_EQ("value", db_->GetRecord("key")); } ``` ### Key Implementation Details When implementing these callbacks, follow these patterns: - **Declare as static**: Both methods must be declared as `static void` within the fixture class definition. - **Define shared state**: Use `static` data members (like `db_` above) to hold resources accessible by all test instances. - **Use assertions**: `SetUpTestSuite` supports assertions like `ASSERT_TRUE`; if an assertion fails, the entire test suite fails immediately. ## Recording Suite-Level Properties During `SetUpTestSuite` or `TearDownTestSuite`, you can call `RecordProperty("key", "value")` to inject metadata into the XML output. These properties become attributes of the `` element in the generated test report, providing valuable context such as database versions or environment configurations for the entire test run. ## Legacy Method Names For backward compatibility, Google Test still supports the deprecated names `SetUpTestCase` and `TearDownTestCase`. However, the modern API uses `SetUpTestSuite` and `TearDownTestSuite` to align with current terminology where "test suite" replaced "test case" in the framework's vocabulary. New code should always use the `*TestSuite` variants. ## Summary - **SetUpTestSuite** runs once before the first test; **TearDownTestSuite** runs once after the last test. - These methods are `static` and execute without a fixture instance, requiring `static` members for shared state. - The framework stores function pointers in the `TestSuite` object and executes them via `RunSetUpTestSuite()` and `RunTearDownTestSuite()`. - Suite-level properties recorded via `RecordProperty` appear as XML attributes on the `` element. - Legacy names `SetUpTestCase` and `TearDownTestCase` exist but are deprecated. ## Frequently Asked Questions ### What is the difference between SetUpTestSuite and SetUp? `SetUpTestSuite` is a static method that executes **once per suite** before any tests run, while `SetUp()` is a non-static virtual method that executes **before every individual test**. Use `SetUpTestSuite` for expensive initialization shared across tests (like database connections) and `SetUp()` for test-specific preparation that must be fresh for each test case. ### Why are SetUpTestSuite and TearDownTestSuite static methods? These methods are static because Google Test invokes them **without creating an instance of the test fixture class**. The framework calls these callbacks at the suite level to initialize resources before any test objects exist, and cleans up after all test objects have been destroyed. ### Can SetUpTestSuite use assertions to fail the test suite? Yes. `SetUpTestSuite` can use Google Test assertions like `ASSERT_TRUE()`, `ASSERT_EQ()`, or `ASSERT_NE()`. If an assertion fails inside `SetUpTestSuite`, the framework marks the entire test suite as failed and skips executing the individual tests, as demonstrated in the database connection example where `ASSERT_TRUE(db_->Open())` validates the shared resource. ### How do I record metadata for the entire test suite? Call `RecordProperty("property_name", "value")` inside either `SetUpTestSuite` or `TearDownTestSuite`. According to the Google Test source implementation, properties recorded at this scope become XML attributes on the `` element in the test output, rather than attributes on individual `` elements.