So far, our tests have called a function, and executed our function exactly as it would be executed in the real world. This is a useful default behaviour, as it means what we're testing is as close as possible to what our program actually does.

However, there are some situations where this is not desirable. For example:

What if our function performs some high-impact action, like placing an order or calling an external API that bills us for usage? We don't want our test to make impactful changes outside of their scope or to cost money.
What if a dependency that our function is using takes a really long time to calculate its result? We don't want our tests to be slowed down by some dependency that they're not directly interested in.
What if our function has a different behaviour based on inputs from sensors, the current time, or the current date? We might want to test how our function behaves at weekends, but we want to our tests to be runnable and useful at all times, not just weekends.

The answer is to isolate the code we want to test from its dependencies. Google Mock is a library, bundled with Google Test, that lets you create "fake" versions of your dependencies, called mocks.

Dependency Injection

To use mocks, our code must be structured in a way that allows dependencies to be replaced. This is called Dependency Injection. The idea is to have your class depend on an abstract interface, not a concrete implementation.

This isn't just useful for testing - it makes our code more flexible in general.

For example, let's imagine we want our Greeter to behave differently based on what the current day is. To set this up, let's have our Greeter class be influenced by a DateProvider service that it uses.

Step 1: Define an Interface

First, we define an abstract interface that our Greeter will depend on. Our service will provide a getDayOfWeek() function that returns an integer representing the current day:

greeter/include/greeter/IDateProvider.h

1#pragma once
2#include <memory>
3
4// Abstract interface for a date provider
5class IDateProvider {
6public:
7  virtual ~IDateProvider() = default;
8  // 0=Sun, 1=Mon, ...
9  virtual int getDayOfWeek() const = 0;
10};
11
12// Factory function to create the real provider
13std::unique_ptr<IDateProvider> createDateProvider();

Step 2: Create a Real Implementation

Next, we provide a "real" implementation that could be used in the production application. This implementation will use std::chrono to get the current date:

greeter/src/ChronoDateProvider.cpp

1#include <greeter/IDateProvider.h>
2#include <chrono>
3
4class ChronoDateProvider : public IDateProvider {
5public:
6  int getDayOfWeek() const override {
7    using namespace std::chrono;
8    const auto now{system_clock::now()};
9    const weekday wd{floor<days>(now)};
10    
11    // C++ weekday is 0-6 for Sun-Sat
12    return wd.c_encoding();
13  }
14};
15
16std::unique_ptr<IDateProvider> createDateProvider() {
17  return std::make_unique<ChronoDateProvider>();
18}

Step 3: Inject the Dependency

Finally, we'll refactor the Greeter class to use this ChronoDateProvider by default, but it will also allow for a different provider to be injected at construction:

greeter/include/greeter/Greeter.h

1#pragma once
2#include <string>
3#include <memory>
4#include "IDateProvider.h"
5
6class Greeter {
7public:
8  // Default constructor uses ChronoDateProvider
9  Greeter();
10  
11  // Greeter allows for a different dependency
12  // to be injected for testing/flexibility
13  explicit Greeter(
14    std::unique_ptr<IDateProvider> provider
15  );
16  
17  std::string greet() const;
18
19private:
20  std::unique_ptr<IDateProvider> date_provider_;
21};

The greet() method now uses the provider to get the day of the week:

greeter/src/Greeter.cpp

1#include <greeter/Greeter.h>
2
3// Forward declaration of the factory function
4std::unique_ptr<IDateProvider> createDateProvider();
5
6// Default constructor uses ChronoDateProvider
7Greeter::Greeter() :
8  date_provider_(createDateProvider()) {}
9
10// Constructor that takes a custom provider
11Greeter::Greeter(
12  std::unique_ptr<IDateProvider> provider
13) : date_provider_(std::move(provider)) {}
14
15std::string Greeter::greet() const {
16  int day{date_provider_->getDayOfWeek()};
17  std::string day_str;
18  switch (day) {
19    case 1: day_str = "Happy Monday!"; break;
20    case 5: day_str = "Happy Friday!"; break;
21    default: day_str = "Have a nice day!"; break;
22  }
23  return day_str + " Hello from the Greeter class!";
24}

Our GreeterLib now has a new source and header file, so we should update our CMakeLists.txt accordingly.

The library is now also using a modern C++ feature (std::chrono from C++20) so we should specify that requirement:

greeter/CMakeLists.txt

1cmake_minimum_required(VERSION 3.23)
2add_library(GreeterLib)
3
4target_compile_features(GreeterLib PUBLIC cxx_std_20)
5
6target_sources(GreeterLib
7  PRIVATE
8    src/Greeter.cpp
9    src/ChronoDateProvider.cpp
10  PUBLIC
11    FILE_SET public_headers
12    TYPE HEADERS
13    BASE_DIRS "include/"
14    FILES
15      "include/greeter/Greeter.h"
16      "include/greeter/IDateProvider.h"
17)

Writing the Mock Test

Now we can write a test that isolates Greeter from the real ChronoDateProvider.

Step 1: Create the Mock Class

In our test file, we create a mock implementation of IDateProvider using Google Mock's MOCK_METHOD macro. The arguments for MOCK_METHOD are:

The return type of the function we're mocking
The name of the function we're mocking
The argument types that it expects - eg (int, bool, float) . In our case, getDayOfWeek() takes no arguments
Any qualifiers we need or want to use, such as (const, override)

Mocking the getDayOfWeek() function of an IDateProvider would look like this:

tests/main.cpp

1#include <gmock/gmock.h>
2#include <gtest/gtest.h>
3#include <greeter/Greeter.h>
4
5// Mock implementation of the IDateProvider interface
6class MockDateProvider : public IDateProvider {
7public:
8  // getDayOfWeek returns int, takes no arguments, and is
9  // const.  We can also state that this is an override
10  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
11};

Step 2: Create the Mock Object

Inside our test case, we create an instance of our mock:

1#include <gmock/gmock.h>
2#include <gtest/gtest.h>
3#include <greeter/Greeter.h>
4
5class MockDateProvider : public IDateProvider {
6public:
7  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
8};
9
10TEST(GreeterWithMockDate, GreetsForMonday) {
11  auto mock_provider{std::make_unique<MockDateProvider>()};
12  
13  // ...
14}

Step 3: Configure the Mock Object

Then, using EXPECT_CALL, we tell the mock what to expect and how to behave.

In the following example, we're saying that we expect this test to eventually result in the getDayOfWeek() function of our mock_provider to be called a single time.

Additionally, we configure the mock such that the function should return 1 (corresponding to Monday) on that call:

1#include <gmock/gmock.h>
2#include <gtest/gtest.h>
3#include <greeter/Greeter.h>
4
5// Mock implementation of the IDateProvider interface
6class MockDateProvider : public IDateProvider {
7public:
8  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
9};
10
11TEST(GreeterWithMockDate, GreetsForMonday) {
12  auto mock_provider{std::make_unique<MockDateProvider>()};
13
14  EXPECT_CALL(*mock_provider, getDayOfWeek())
15    .WillOnce(testing::Return(1));
16    
17  // ...
18}

Google Mocks includes a huge suite of capabilities to configure how our mocks should behave. The official documentation has many examples.

Step 4: Inject the Dependency

Now, we create an instance of our Greeter. We pass our mock to the constructor, causing greeter to use it rather than its default ChronoDateProvider:

1#include <gmock/gmock.h>
2#include <gtest/gtest.h>
3#include <greeter/Greeter.h>
4
5class MockDateProvider : public IDateProvider {
6public:
7  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
8};
9
10TEST(GreeterWithMockDate, GreetsForMonday) {
11  auto mock_provider{std::make_unique<MockDateProvider>()};
12
13  EXPECT_CALL(*mock_provider, getDayOfWeek())
14    .WillOnce(testing::Return(1));
15
16  Greeter greeter(std::move(mock_provider));
17  
18  // ...
19}

Step 5: Assert the Outcome

Finally, we write our assertion. Our mock is always going to report the day as being 1, so we ensure our greet() function is behaving correctly if it reports the day as Monday:

1#include <gmock/gmock.h>
2#include <gtest/gtest.h>
3#include <greeter/Greeter.h>
4
5class MockDateProvider : public IDateProvider {
6public:
7  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
8};
9
10TEST(GreeterWithMockDate, GreetsForMonday) {
11  auto mock_provider{std::make_unique<MockDateProvider>()};
12
13  EXPECT_CALL(*mock_provider, getDayOfWeek())
14    .WillOnce(testing::Return(1));
15
16  Greeter greeter(std::move(mock_provider));
17
18  EXPECT_EQ(
19    greeter.greet(),
20    "Happy Monday! Hello from the Greeter class!"
21  );
22}

This test is now completely deterministic. It will always test the "Monday" logic, regardless of what day it's actually run on.

Step 6: Linking against GMock

Before building our tests, let's make sure we're still linking against the gmock library.

We may also want to replace gtest_main library with gmock_main. This will create a main function that sets up both Google Test and Google Mock. This is not strictly necessary in this example, but will be required if we use more advanced capabilities of Google Mock:

tests/main.cpp

1cmake_minimum_required(VERSION 3.23)
2
3find_package(GTest REQUIRED)
4
5add_executable(GreeterTests main.cpp)
6
7target_link_libraries(GreeterTests PRIVATE
8  GreeterLib
9  GTest::gtest
10  GTest::gmock
11  GTest::gtest_main
12  GTest::gmock_main
13)
14
15gtest_discover_tests(GreeterTests)

Step 7: Run the Tests

To ensure everything is working, let's configure and build the project:

1cmake --preset default

1cmake --build --preset default

If we run our application, we should see it log today's message:

1./build/app/GreeterApp

1Happy Friday! Hello from the Greeter class!

However, when we're running our tests, our injected dependency will convince the library that it's always Monday, giving us reliable testing behaviour:

1ctest --preset default

11/1 Test #1: GreeterWithMockDate.GreetsForMonday ...   Passed
2
3100% tests passed, 0 tests failed out of 1

Parameterized Tests with Mocks

We can combine the power of mocking with the data-driven approach of parameterized tests.

Let's create a test that verifies the correct greeting for multiple days of the week:

1#include <gmock/gmock.h>
2#include <gtest/gtest.h>
3#include <greeter/Greeter.h>
4#include <tuple>
5
6class MockDateProvider : public IDateProvider {
7public:
8  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
9};
10
11// A parameterized test fixture
12class GreeterDayTest :
13  public testing::TestWithParam<
14    std::tuple<int, std::string>
15  > {};
16
17TEST_P(GreeterDayTest, GreetsCorrectlyForDay) {
18  auto [day_of_week, expected_greeting] = GetParam();
19
20  auto mock_provider{std::make_unique<MockDateProvider>()};
21  EXPECT_CALL(*mock_provider, getDayOfWeek())
22    .WillOnce(testing::Return(day_of_week));
23
24  Greeter greeter(std::move(mock_provider));
25  EXPECT_EQ(greeter.greet(), expected_greeting);
26}
27
28// Instantiate the test suite with our test data
29INSTANTIATE_TEST_SUITE_P(
30  DayOfWeekGreetings,
31  GreeterDayTest,
32  testing::Values(
33    std::make_tuple(
34      1,
35      "Happy Monday! Hello from the Greeter class!"
36    ),
37    std::make_tuple(
38      2,
39      "Have a nice day! Hello from the Greeter class!"
40    ),
41    std::make_tuple(
42      5,
43      "Happy Friday! Hello from the Greeter class!"
44    )
45  )
46);

Now, ctest will run three separate, deterministic tests, one for each entry in our Values list, all using the same mock-based logic.

1cmake --build --preset default

1ctest --preset default

1...
2100% tests passed, 0 tests failed out of 3
3...

Summary

This lesson introduced three important concepts for writing more advanced tests:

Dependency Injection: A design pattern where a class receives its dependencies from an external source rather than creating them itself. This decouples your classes and is a prerequisite for effective mocking.
Mocking with Google Mock: We used Google Mock to create "fake" versions of our dependencies. The MOCK_METHOD macro generates a mock implementation of a method.
Controlling Behavior with EXPECT_CALL: We used EXPECT_CALL to define the expected behavior of our mock objects (e.g., what they should return when a method is called). This allows us to create specific, controlled scenarios for our tests.

Dependency Injection and Mocking

Dependency Injection

Step 1: Define an Interface

greeter/include/greeter/IDateProvider.h

Step 2: Create a Real Implementation

greeter/src/ChronoDateProvider.cpp

Step 3: Inject the Dependency

greeter/include/greeter/Greeter.h

greeter/src/Greeter.cpp

greeter/CMakeLists.txt

Writing the Mock Test

Step 1: Create the Mock Class

tests/main.cpp

Step 2: Create the Mock Object

Step 3: Configure the Mock Object

Step 4: Inject the Dependency

Step 5: Assert the Outcome

Step 6: Linking against GMock

tests/main.cpp

Step 7: Run the Tests

Parameterized Tests with Mocks

Summary

Testing Executables

Managing C++ Projects Using CMake