An introduction to the build pipeline, and how we can orchestrate it manually

Before working with CMake, it's useful to understand the tools it orchestrates. This lesson guides you through setting up a C++ toolchain.

Building C++ Programs

Walking through the steps of the C++ compilation process, from source code to machine code.

The Compilation Pipeline

The linker's role in the build process, how it resolves symbols to combine object files, and how to troubleshoot common errors.

Object Files and the Linking Process

The difference between static and dynamic libraries, how to create them, and the trade-offs between them.

Static and Shared Libraries

The C++ Build Process

Recommended approaches for managing large projects and the libraries that they depend on

Learn how to structure your C++ projects for scalability and maintainability, from basic directory layouts to managing multiple modules.

Organizing a C++ Project

Learn to manage third-party libraries in C++, covering include/library paths, static vs. shared libraries, versioning, and platform differences.

Managing Libraries and Dependencies

An introduction to traditional build tools like Makefiles and IDE projects, highlighting the maintenance, scalability, and cross-platform challenges that result

Automated Build Systems and Their Limitations

Project Structure and Dependency Management

Setting up CMake and creating your first project

An introduction to CMake, the cross-platform, open-source meta-build system that solves the core challenges of C++ project management.

Why CMake?

A step-by-step guide to installing CMake. We'll explore command-line, GUI, and IDE workflows, and how to configure your compiler.

Setting Up a CMake Environment

Creating the bare minimum `CMakeLists.txt` file and build up to a project with an executable and a library, learning the fundamental commands along the way.

Writing a CMakeLists File

Learn the two-stage process of building a CMake project. This lesson covers configuring, generating, building, running, and troubleshooting common errors.

Building and Running CMake Projects

Learn how to organize large C++ projects in CMake using subdirectories and the `add_subdirectory()` command to create modular, maintainable builds.

CMake Project Structure and Subdirectories

Introducing CMake

Exploring CMake's programming features, caching mechanisms, and interactions with the file system

A primer on the fundamental building blocks of the CMake language: variables, string interpolation, and logging messages.

CMake Variables and Logging

Discover the CMake Cache, the mechanism for storing persistent user-configurable options, and learn how to create and manage cached variables.

The CMake Cache

Exploring CMake's command syntax and its list data type, including how to create, manipulate, and use lists in your projects.

CMake Commands, Arguments, and Lists

Transform your static build descriptions into dynamic scripts with CMake's control flow commands, if() and foreach().

CMake Conditionals and Loops

Exploring CMake's `file()` command, covering how to read, write, copy, and glob files, and how to manipulate paths.

Working with the File System

Learn to create reusable logic with CMake functions and macros, and how to organize them into modules for clean, scalable build systems.

Modularizing CMake Code

CMake Language and Fundamentals

Learn more about targets, and how their properties and links are the foundation of modern CMake

Learn to work with target properties - understanding their purpose, setting and updating them, and retrieving them when your build requires it

Target Properties

Learn about target types, and how the `PUBLIC`, `PRIVATE`, and `INTERFACE` keywords control how properties are shared.

Relationships Between Targets

Discover how CMake's `target_link_libraries()` command builds a dependency graph, and how it uses this graph to automatically manage transitive dependencies and link order.

Indirect Relationships and the Dependency Graph

Learn to use abstract target types like `INTERFACE`, `ALIAS`, and `IMPORTED` to model complex project needs, organize build properties, and integrate pre-compiled binaries.

Using `INTERFACE`, `ALIAS`, and `IMPORTED` Libraries

Adding support for user-configurable library types and an initial introduction to target installation.

Using Shared Libraries

Targets and Dependencies

Learn how to manage multiple build configurations within the same project, and how to create scripts that adapt to the environment

Learn how CMake manages different build configurations like Debug and Release, the difference between generator types, and how to apply settings conditionally using modern techniques.

Build Configurations (Debug, Release, etc.)

Learn the tools and patterns needed to write portable CMakeLists.txt files that work seamlessly across platforms and compilers

Cross-Platform Configurations

Learn to write architecture-aware CMake scripts for 32/64-bit systems and Apple's Universal Binaries (Intel/ARM).

Handling Different Architectures

Learn to build for different operating systems and architectures using CMake's cross-compilation support and toolchain files.

Cross-Compilation and Toolchain Files

Platforms and Build Configurations

Learn how to add external libraries to our build, and how to create our own packages for others to use

Learn to find and use pre-installed libraries with `find_package()`, understanding Module vs. Config mode and the power of imported targets

Finding Dependencies using `find_package()`

Learn how to make your libraries consumable by other projects using CMake by turning your build-tree into a distributable install-tree.

Creating a Consumable Package

Learn how to consume a CMake package you've installed, completing the producer-consumer cycle. We'll cover using `find_package()` and how to point CMake to your library's location

Using Installed Packages

Learn how to create self-contained, reproducible builds by fetching dependencies from source using `FetchContent()` and `ExternalProject_Add()`.

Fetching External Dependencies

Creating and Consuming Packages

Integrating the vcpkg and Conan package managers to handle external dependencies

Learn to manage C++ dependencies effortlessly with the vcpkg package manager and its seamless CMake integration using toolchain files and manifests.

Integrating CMake and vcpkg

Learn the day-to-day commands for managing dependencies with vcpkg and how to guarantee reproducible builds using baselines and version overrides

vcpkg Commands and Versioning

Combine vcpkg with CMake's cross-compilation capabilities. Learn to use triplets to target different architectures and chain-load toolchain files

Cross-Compiling with vcpkg

Discover Conan, the binary-first C++ package manager, and learn how to integrate it with CMake using profiles and lockfiles for fast, reproducible builds.

Using Conan with CMake

Learn to cross-compile C++ projects with Conan, using build and host profiles to manage dependencies for different platforms.

Cross-Compilation with Conan

Package Managers

Introducing presets, allowing us to simplify our workflow and share common configurations across our team

Learn the fundamentals of CMake Presets. This lesson introduces `CMakePresets.json` to simplify complex build commands.

CMake Presets

Learn to structure your CMake presets with inheritance and customize them for your local environment using `CMakeUserPresets.json`.

User Presets and Inheritance

Learn to make your CMake presets portable by using environment variables and conditional logic to adapt to different machine configurations.

Environment Variables and Conditional Presets

Learn how to extend the build process beyond simple compilation by integrating external tools and custom commands

Learn how to use generator expressions `$<...>` for build-time conditional logic.

Generator Expressions and Conditional Logic

Learn how to attach commands to specific points in a target's build lifecycle using `add_custom_command(TARGET)` for tasks like post-build file copying.

Integrating Tools with `add_custom_command()`

Learn to integrate code generators like Protobuf into your build process using `add_custom_command()`, creating automated file-level dependencies in CMake.

Generating Files with Protobuf and `add_custom_command()`

Custom Commands

An introduction to automating common workflow chores by creating custom targets

Learn to create standalone, non-code targets using add_custom_target() for utility tasks like code formatting and documentation generation.

Custom Targets and Build Utilities

Using the Clang-Format tool to automatically enforce a consistent coding style, and integrating it into our build using a custom CMake target

Using Clang-Format

An introduction to file sets and the `target_sources()` command, allowing us to manage our header files in a more controlled way

Using File Sets

A step-by-step guide to integrating Doxygen into your CMake build process for automated C++ documentation.

Generating Documentation with Doxygen

Custom Targets

Integrate automated tests into a CMake project using CTest, GoogleTest, and GoogleMock

Learn the fundamentals of automated testing in C++ with CTest. Create your first test suite, register tests with `add_test()`, and run them with the `ctest` command.

Automated Testing and CTest

Learn to refactor manual C++ tests into a professional test suite using the GoogleTest framework, managed by vcpkg and integrated with CTest.

Integrating GoogleTest with CMake

Learn to use a wide range of assertions, write data-driven parameterized tests, and isolate dependencies with Google Mock.

Assertions and Parameterized Tests

Learn how to isolate dependencies that our project uses, and then how to replace those dependencies at test time using Google Mock.

Dependency Injection and Mocking

Learn the standard pattern for testing application logic by refactoring it into a linkable library

Testing Executables

Move beyond individual tests to manage a full test suite. Learn to organize tests, run tests in parallel, filter by labels, and measure our code coverage

Managing a Test Suite

Automated Testing

Using static and dynamic analysis in CMake projects to automatically detect memory bugs, performance issues, and problematic code

Learn to find memory bugs at runtime by integrating AddressSanitizer (ASan) into a CMake project

Using AddressSanitizer (ASan)

Adding benchmarks to our build to measure the performance of our code, and track how it changes over time

Using Google Benchmark

Integrating Clang-Tidy to enforce good practices and find bugs before we even compile

Using Clang-Tidy

Automated Analysis

Automating the entire development lifecycle using Git for souce control, GitHub Actions for cloud builds, and CPack to create distributable packages and installers.

An introduction to Git, the version control system that underpins modern collaborative software development and automated build pipelines.

Source Control with Git

Learn how to automate your build and test process with Continuous Integration (CI) and a build server. This lesson provides a guide to creating a GitHub Actions workflow for a CMake project.

Build Servers and Continuous Integration

Learn to package your C++ projects using CMake's CPack. This lesson covers creating developer ZIP archives and professional Windows MSI installers with components.

Packaging with CPack

Learn to automate the packaging process by integrating CPack with a multi-platform GitHub Actions workflow

Packaging with GitHub Actions

Learn to automate the creation of a professional Windows installer by integrating CPack, the WiX Toolset, and a multi-platform GitHub Actions workflow.

Creating Installers with CPack and GitHub Actions

Learn to automate the release process using a GitHub Actions workflow that builds, packages, and publishes artifacts to a GitHub Release

Deployment with GitHub Releases

Continuous Integration and Packaging

If you have a basic grasp of C++ but find the build process intimidating, this course is for you. We assume you know the language, but not how to manage large projects.

Manage complex, cross-platform builds using industry-standard tools. Create scalable build systems that automate the entire development lifecycle.

This course is a comprehensive deep-dive into the entire C++ build ecosystem, centered around the power and flexibility of modern CMake. We leave no stone unturned.

Start with a foundational understanding of compilers, linkers, static vs. shared libraries, and object files.

The Full Build Pipeline

Learn every aspect of the CMake language, from variables and control flow to functions, modules, and generator expressions.

Complete CMake Language Mastery

Master the modern target-centric paradigm, including properties, usage requirements, and abstract targets.

Advanced Target Management

Explore every method for handling dependencies, from `find_package` and `FetchContent` to vcpkg and Conan, including versioning and cross-compilation.

In-Depth Dependency Management

Integrate a full suite of professional tools for testing (CTest, GoogleTest), analysis (ASan, Clang-Tidy), and packaging (CPack).

Total Workflow Automation

Build a fully automated deployment pipeline that takes your code from a Git push to a published GitHub Release with multi-platform installers.

End-to-End CI/CD and Deployment

What You'll Learn

Become a software engineer with C++.  Starting from the basics, we guide you step by step along the way

Intro to C++ Programming

If you're completely new to programming or want a thorough introduction, consider starting with our free introductory course:

New to Programming?

Managing C++ Projects Using CMake

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:


<CodeFile path="greeter/include/greeter/IDateProvider.h" status="New">


```c++
#pragma once
#include <memory>

// Abstract interface for a date provider
class IDateProvider {
public:
  virtual ~IDateProvider() = default;
  // 0=Sun, 1=Mon, ...
  virtual int getDayOfWeek() const = 0;
};

// Factory function to create the real provider
std::unique_ptr<IDateProvider> createDateProvider();
```


</CodeFile>


### 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:


<CodeFile path="greeter/src/ChronoDateProvider.cpp" status="New">


```c++
#include <greeter/IDateProvider.h>
#include <chrono>

class ChronoDateProvider : public IDateProvider {
public:
  int getDayOfWeek() const override {
    using namespace std::chrono;
    const auto now{system_clock::now()};
    const weekday wd{floor<days>(now)};
    
    // C++ weekday is 0-6 for Sun-Sat
    return wd.c_encoding();
  }
};

std::unique_ptr<IDateProvider> createDateProvider() {
  return std::make_unique<ChronoDateProvider>();
}
```


</CodeFile>


### 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:


<CodeFile path="greeter/include/greeter/Greeter.h" status="Updated">


```c++
#pragma once
#include <string>
#include <memory>
#include "IDateProvider.h"

class Greeter {
public:
  // Default constructor uses ChronoDateProvider
  Greeter();
  
  // Greeter allows for a different dependency
  // to be injected for testing/flexibility
  explicit Greeter(
    std::unique_ptr<IDateProvider> provider
  );
  
  std::string greet() const;

private:
  std::unique_ptr<IDateProvider> date_provider_;
};
```


</CodeFile>


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


<CodeFile path="greeter/src/Greeter.cpp" status="Updated">


```c++
#include <greeter/Greeter.h>

// Forward declaration of the factory function
std::unique_ptr<IDateProvider> createDateProvider();

// Default constructor uses ChronoDateProvider
Greeter::Greeter() :
  date_provider_(createDateProvider()) {}

// Constructor that takes a custom provider
Greeter::Greeter(
  std::unique_ptr<IDateProvider> provider
) : date_provider_(std::move(provider)) {}

std::string Greeter::greet() const {
  int day{date_provider_->getDayOfWeek()};//<h>
  std::string day_str;
  switch (day) {
    case 1: day_str = "Happy Monday!"; break;
    case 5: day_str = "Happy Friday!"; break;
    default: day_str = "Have a nice day!"; break;
  }
  return day_str + " Hello from the Greeter class!";
}
```


</CodeFile>


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:


<CodeFile path="greeter/CMakeLists.txt" status="Updated">


```c++
#<cmake>
cmake_minimum_required(VERSION 3.23)
add_library(GreeterLib)

target_compile_features(GreeterLib PUBLIC cxx_std_20)#<h>

target_sources(GreeterLib
  PRIVATE
    src/Greeter.cpp
    src/ChronoDateProvider.cpp#<h>
  PUBLIC
    FILE_SET public_headers
    TYPE HEADERS
    BASE_DIRS "include/"
    FILES
      "include/greeter/Greeter.h"
      "include/greeter/IDateProvider.h"#<h>
)
```


</CodeFile>


<Pw>


## 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:


<CodeFile path="tests/main.cpp" status="Updated">


```c++
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <greeter/Greeter.h>

// Mock implementation of the IDateProvider interface
class MockDateProvider : public IDateProvider {//<h>
public://<h>
  // getDayOfWeek returns int, takes no arguments, and is
  // const.  We can also state that this is an override
  MOCK_METHOD(int, getDayOfWeek, (), (const, override));//<h>
};//<h>
```


</CodeFile>


### Step 2: Create the Mock Object


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


```c++
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <greeter/Greeter.h>

class MockDateProvider : public IDateProvider {
public:
  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
};

TEST(GreeterWithMockDate, GreetsForMonday) {//<h>
  auto mock_provider{std::make_unique<MockDateProvider>()};//<h>
  
  // ...
}//<h>
```


### 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:


```c++
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <greeter/Greeter.h>

// Mock implementation of the IDateProvider interface
class MockDateProvider : public IDateProvider {
public:
  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
};

TEST(GreeterWithMockDate, GreetsForMonday) {
  auto mock_provider{std::make_unique<MockDateProvider>()};

  EXPECT_CALL(*mock_provider, getDayOfWeek())//<h>
    .WillOnce(testing::Return(1));//<h>
    
  // ...
}
```


Google Mocks includes a huge suite of capabilities to configure how our mocks should behave.  The [official documentation](https://google.github.io/googletest/gmock_cook_book.html) 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`:  


```c++
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <greeter/Greeter.h>

class MockDateProvider : public IDateProvider {
public:
  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
};

TEST(GreeterWithMockDate, GreetsForMonday) {
  auto mock_provider{std::make_unique<MockDateProvider>()};

  EXPECT_CALL(*mock_provider, getDayOfWeek())
    .WillOnce(testing::Return(1));

  Greeter greeter(std::move(mock_provider));//<h>
  
  // ...
}
```


### 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:


```c++
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <greeter/Greeter.h>

class MockDateProvider : public IDateProvider {
public:
  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
};

TEST(GreeterWithMockDate, GreetsForMonday) {
  auto mock_provider{std::make_unique<MockDateProvider>()};

  EXPECT_CALL(*mock_provider, getDayOfWeek())
    .WillOnce(testing::Return(1));

  Greeter greeter(std::move(mock_provider));

  EXPECT_EQ(//<h>
    greeter.greet(),//<h>
    "Happy Monday! Hello from the Greeter class!"//<h>
  );//<h>
}
```


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:


<CodeFile path="tests/main.cpp" status="Updated">


```c++
#<cmake>
cmake_minimum_required(VERSION 3.23)

find_package(GTest REQUIRED)

add_executable(GreeterTests main.cpp)

target_link_libraries(GreeterTests PRIVATE
  GreeterLib
  GTest::gtest
  GTest::gmock#<h>
  GTest::gtest_main#<d>
  GTest::gmock_main#<h>
)

gtest_discover_tests(GreeterTests)
```


</CodeFile>


### Step 7: Run the Tests


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


```c++
//<ti>
cmake --preset default
```


```c++
//<ti>
cmake --build --preset default
```


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


```c++
//<ti>
./build/app/GreeterApp
```


```c++
//<o>
Happy 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:


```c++
//<ti>
ctest --preset default
```


```c++
//<o>
1/1 Test #1: GreeterWithMockDate.GreetsForMonday ...   Passed

100% 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:


```c++
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <greeter/Greeter.h>
#include <tuple>

class MockDateProvider : public IDateProvider {
public:
  MOCK_METHOD(int, getDayOfWeek, (), (const, override));
};

// A parameterized test fixture
class GreeterDayTest :
  public testing::TestWithParam<
    std::tuple<int, std::string>
  > {};

TEST_P(GreeterDayTest, GreetsCorrectlyForDay) {
  auto [day_of_week, expected_greeting] = GetParam();

  auto mock_provider{std::make_unique<MockDateProvider>()};
  EXPECT_CALL(*mock_provider, getDayOfWeek())
    .WillOnce(testing::Return(day_of_week));

  Greeter greeter(std::move(mock_provider));
  EXPECT_EQ(greeter.greet(), expected_greeting);
}

// Instantiate the test suite with our test data
INSTANTIATE_TEST_SUITE_P(
  DayOfWeekGreetings,
  GreeterDayTest,
  testing::Values(
    std::make_tuple(
      1,
      "Happy Monday! Hello from the Greeter class!"
    ),
    std::make_tuple(
      2,
      "Have a nice day! Hello from the Greeter class!"
    ),
    std::make_tuple(
      5,
      "Happy Friday! Hello from the Greeter class!"
    )
  )
);
```


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


```c++
//<ti>
cmake --build --preset default
```


```c++
//<ti>
ctest --preset default
```


```c++
//<o>
...
100% tests passed, 0 tests failed out of 3
...
```


<Aside>


### The Dangers of Mocking


Mocks are useful when used to solve specific problems like those listed in the introduction, but we shouldn't overuse them.  That's missing the point of testing, which is to catch errors that would affect our program in its real implementation.


By testing with a mock, we are testing against an **assumption** of how the real dependency behaves. If the real `ChronoDateProvider` had a bug and returned incorrect day numbers, our test suite would pass even though, in the real world, our library would not work correctly.


We could address this by adding tests for `ChronoDateProvider` specifically, or by adding additional `Greeter` tests that do **not** mock the dependency, and instead work around its non-deterministic output.


</Aside>


## 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.

<Preview>


### Advanced Testing Topics


We now know how to write more sophisticated **individual** tests. But how do you manage a test suite with hundreds or thousands of tests? How do we organize our test code, run only a specific subset of tests, and measure how much of our code is actually being tested?


In the next lesson, we will zoom out from writing single tests to managing the entire test suite. We'll cover test organization strategies, advanced CTest features like parallel execution and filtering, and how to perform code coverage analysis to find gaps in our testing.


</Preview>


</Pw>

Google Test Integration with vcpkg

Advanced Unit Testing Topics

Advanced Guide

Assertions Reference

For Dummies

Cookbook

Back to Basics: Testing in C++ - Phil Nash

Mocks Aren't Stubs

Master advanced C++ unit testing with this Google Test tutorial. Learn the difference between ASSERT and EXPECT, how to use parameterized tests for data-driven validation, and how to isolate dependencies with Google Mock for robust, deterministic tests.

Dependency Injection and Mocking

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake