When do I use this in production?

For any C++ codebase where regressions matter: unit tests protect refactors, document behavior, and run in CI with ctest or direct test binaries.

What should I read before this?

Basic C++ and CMake help. Follow the series “previous post” links or the [series index](/blog/cpp-series-index/).

Where can I learn more?

Official GoogleTest docs, Assertions reference, and Death Tests section on google.github.io/googletest.

Google Test (gtest) for C++: From Setup to TEST, Fixtures, and CI

2026년 3월 3일 · 20분 읽기 · 수정 2026년 3월 12일 Intermediate tutorial

이 글의 핵심

Learn gtest: install via FetchContent or vcpkg, write TEST/TEST_F, use EXPECT_* and ASSERT_*, parameterized suites, death tests, filters, XML output, and production test layout.

Introduction: “I refactored and something else broke”

Without tests, refactors hide regressions until production. Unit tests verify functions and classes against expected outputs so CI can catch breaks on every commit.

If calculate changes from a + b to a * b by mistake, EXPECT_EQ(calculate(2, 3), 5) fails immediately with a clear message.

Environment: Google Test via FetchContent, vcpkg (vcpkg install gtest), or Conan. g++/Clang C++14+; on Windows, MSVC + vcpkg is a common combo.

Link gtest_main so you do not write main; or link gtest and provide RUN_ALL_TESTS() yourself.

CMake + FetchContent (minimal)

include(FetchContent)
FetchContent_Declare(
    googletest
    GIT_REPOSITORY https://github.com/google/googletest.git
    GIT_TAG release-1.12.1
)
FetchContent_MakeAvailable(googletest)
enable_testing()
add_executable(myapp_test test_main.cpp)
target_link_libraries(myapp_test PRIVATE gtest_main)
add_test(NAME myapp_test COMMAND myapp_test)

vcpkg

vcpkg install gtest

find_package(GTest REQUIRED)
target_link_libraries(myapp_test PRIVATE GTest::gtest_main)

Basic assertions

EXPECT_*: continue after failure.
ASSERT_*: stop the test on failure (use when later checks depend on earlier ones, e.g. non-null pointer).

String: EXPECT_STREQ for const char*. Floating point: EXPECT_NEAR / EXPECT_DOUBLE_EQ.

Exceptions: EXPECT_THROW(expr, Type), EXPECT_NO_THROW.

Fixtures: TEST_F

Derive from ::testing::Test, override SetUp / TearDown per test, or SetUpTestSuite / TearDownTestSuite once per suite (e.g. shared DB—still design tests to avoid order dependence).

Parameterized tests

TestWithParam<T>, TEST_P, INSTANTIATE_TEST_SUITE_P, GetParam(). Use Combine / Values / Range for data-driven cases.

Death tests

EXPECT_DEATH / ASSERT_DEATH verify that code aborts or exits with expected stderr. Name suites *DeathTest when required. Use EXPECT_DEATH_IF_SUPPORTED on limited platforms.

Patterns: AAA, Given-When-Then

Keep one logical behavior per test; name tests Method_Condition_ExpectedResult.

TDD cycle

Red → Green → Refactor (see diagram in original).

Common errors

Symptom	Fix
undefined reference to `testing::InitGoogleTest`	Link `gtest_main` or provide `main` + link `gtest`
Multiple definitions of `main`	Do not define `main` when using `gtest_main`
pthread on Linux	`target_link_libraries(... gtest_main Threads::Threads)`
Wrong INSTANTIATE macro	Use `INSTANTIATE_TEST_SUITE_P` (GTest 1.10+)
Death test fails in Release	`assert` disabled under NDEBUG—use Debug or adjust
Flaky CI	Fix nondeterminism; seed RNGs; stable paths

Production

Separate test/ tree; link only production libs + gtest.
--gtest_filter=SmokeTest.* for fast smoke runs.
--gtest_output=xml:report.xml for Jenkins/GitHub Actions.
SCOPED_TRACE in loops; RecordProperty for metadata.

Google Mock #18-2
GDB/LLDB #16-1

Next: Google Mock (#18-2)

Previous: Package managers (#17-2)