Integrating GoogleTest with CMake

With the setup complete, we can now refactor our test.

Step 1: Update the Test Code

First, let's delete the entire contents of tests/main.cpp. We'll replace our manual main() function with a gtest TEST() macro.

1#include <gtest/gtest.h>
2#include <greeter/Greeter.h>
3
4TEST(GreeterAPITests, GetGreetingReturnsCorrectString) {
5  const std::string expected{
6    "Hello from the modular greeter library"
7  };
8  
9  EXPECT_EQ(get_greeting(), expected);
10}

Let's break down the TEST() macro:

• The first argument, GreeterAPITests, is the Test Suite name. This is a way to group related tests.
• The second argument, GetGreetingReturnsCorrectString, is the individual Test Case name.

Test suites and tests have the same naming rules as C++ variables. Within those rules, we can call our test suite and tests whatever we want, but we should be descriptive.

Inside the curly braces, we have the test body. The EXPECT_EQ(val1, val2) macro checks if val1 is equal to val2. If it's not, it registers a failure and prints a detailed message, but allows the test program to continue running other tests.

Step 2: Link the gtest Libraries

Next, we update tests/CMakeLists.txt to link our GreeterTests executable against the libraries provided by gtest.

1cmake_minimum_required(VERSION 3.23)
2find_package(GTest REQUIRED)
3
4add_executable(GreeterTests main.cpp)
5target_link_libraries(GreeterTests PRIVATE
6  GreeterLib
7  GTest::gtest        # The core gtest library 
8  GTest::gtest_main   # Provides a main() function 
9)

• GTest::gtest: This is the core gtest library containing all the assertion macros and test infrastructure.
• GTest::gtest_main: This is a tiny library that contains just one thing: a pre-written main() function that discovers and runs all the TEST() cases in your executable. By linking to it, we save ourselves from writing any boilerplate.

The final step is to tell CTest about our new gtest-based executable. We could use add_test() as before, but the FindGTest module we loaded through our find_package(GTest) command provides a much better way: gtest_discover_tests().

You give it your test executable target, and at build time, it will run the executable with the --gtest_list_tests flag to discover all the TEST() cases inside it. It then automatically creates a separate CTest test for each one, using the full TestSuite.TestCase name.

Let's replace our old add_test() call with this new command:

1cmake_minimum_required(VERSION 3.23)
2find_package(GTest REQUIRED)
3
4add_executable(GreeterTests main.cpp)
5target_link_libraries(GreeterTests PRIVATE
6  GreeterLib GTest::gtest GTest::gtest_main
7)
8
9gtest_discover_tests(GreeterTests)

Now, let's run our test preset from the project root. Remember to clean your build directory first if you're making these changes to an existing project. Also ensure you still have the enable_testing() command in your root CMakeLists.txt file.

1cmake --preset=default

1cmake --build --preset=default

1ctest --preset=default

The CTest output is now much more descriptive. It shows the full, namespaced gtest name, which is helpful for identifying exactly which test passed or failed in a large suite.

1Test project D:/Projects/cmake/build
2    Start 1: GreeterAPITests.GetGreetingReturnsCorrectString
31/1 Test #1: GreeterAPITests.GetGreetingReturnsCorrectString ...   Passed    0.01 sec
4
5100% tests passed, 0 tests failed out of 1
6
7Total Test time (real) =   0.02 sec

Free functions are easy to test, but most non-trivial C++ code is organized into classes. To set the stage for more complex tests, let's refactor our GreeterLib from a free function into a simple class.

This change presents a new challenge for our test. To test the greet() method, we first need to create an instance of the Greeter class.

1#include <gtest/gtest.h>
2#include <greeter/Greeter.h>
3
4TEST(GreeterClassTests, GreetReturnsCorrectString) {
5  Greeter my_greeter; // Create an object
6  EXPECT_EQ(
7    my_greeter.greet(),
8    "Hello from the Greeter class!"
9  );
10}

This works, but if we have many tests for the Greeter class, we'll be repeating the Greeter my_greeter; line in every single test case. And, in real world examples, getting our object into a state where it is ready to be tested can involve significant amounts of code. This is where test fixtures come in.

A test fixture is a class that inherits from testing::Test and is used to manage a shared test environment.

Let's create a fixture for our Greeter tests:

1#include <gtest/gtest.h>
2#include <greeter/Greeter.h>
3
4// A test fixture for Greeter tests
5class GreeterTest : public testing::Test {
6protected:
7  Greeter my_greeter;
8};

We can treat this class like any other - we can add variables and functions to it and inherit more classes from it as needed.

Most commonly, if we need to perform common initialization for a group of tests, we'd define a constructor or override the SetUp() method.

The TEST_F Macro

By using the TEST_F macro (the 'F' stands for Fixture), we tell gtest that this test case belongs to the GreeterTest fixture.

1#include <gtest/gtest.h>
2#include <greeter/Greeter.h>
3
4class GreeterTest : public testing::Test {
5protected:
6  // This object will be created fresh for each TEST_F
7  Greeter my_greeter;
8};
9
10// Use the TEST_F macro to use the fixture
11TEST_F(GreeterTest, GreetReturnsCorrectString) {
12  EXPECT_EQ(
13    my_greeter.greet(),
14    "Hello from the Greeter class!"
15  );
16}

Note that, unlike TEST, the first argument to TEST_F is no longer an arbitrary name - it is now the name of the class that we created to set up our testing requirements.

Before running each test, gtest will create an instance of this GreeterTest class. Our test can then access any of its protected or public members. In our example, the only member is our my_greeter object, but these testing::TEST-derived classes can get as complicated as we need them to be.

This makes the fixture-based pattern useful for more complex tests that require setting up a common state (like opening a file or connecting to a test database) before each test runs.

In this lesson, we transformed our basic, manual test into a test suite using GoogleTest. This unlocks a huge leap forward in the quality and maintainability of our project's tests.

• Using Test Frameworks: We saw how a dedicated testing framework like gtest can eliminate boilerplate and provide utilities that solve common testing requirements.
• vcpkg Integration: We added gtest as a dependency in our vcpkg.json manifest.
• Refactoring to gtest: We replaced our manual main() with a TEST() macro and EXPECT_EQ, and linked against the GTest::gtest and GTest::gtest_main imported targets.
• Automated Discovery: We replaced add_test() with gtest_discover_tests(), which automatically finds and registers all gtest cases with CTest.
• Test Fixtures: We introduced test fixtures (class MyTest : public testing::Test) and the TEST_F() macro as the standard way to manage shared setup and teardown logic for class-based tests.