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

In the last lesson, we took our first steps into automated testing. We created a manual test driver, registered it with `add_test()`, and ran it with CTest. While this worked, it also exposed the limitations of a manual approach.


This lesson introduces **GoogleTest** (often called `gtest`), a feature-rich, industry-standard testing framework for C++. We'll refactor our clunky manual test into a clean and scalable test suite.


We'll manage `gtest` as a dependency with vcpkg, integrate it into our build using CMake, and learn how to automatically discover and register our tests with CTest.


## The Shortcomings of Manual Tests


For reference, here is the test driver we wrote in the last lesson.


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


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

int main() {
  const std::string expected{
    "Hello from the modular greeter library"
  };
  const std::string actual{get_greeting()};

  if (actual != expected) {
    std::cerr << "Test Failed:"
              << "\n  Expected: " << expected
              << "\n  Actual:   " << actual;
    return EXIT_FAILURE;
  }

  std::cout << "Test Passed!";
  return EXIT_SUCCESS;
}
```


</CodeFile>


While it gets the job done for a single check, this approach has several major flaws:

- **Excessive Boilerplate**: Every single assertion requires a verbose `if/else` block, manual error message formatting, and a `return` statement. Adding ten more tests means copying this boilerplate ten more times.
- **Poor Failure Reporting**: Our failure messages are entirely manual. If we forget to print the `expected` and `actual` values, we'll just get a generic "Test Failed!" message with no context.
- **No Test Isolation**: What if we wanted to add a second, unrelated test to this file? If the first test fails, `main()` returns immediately, and the second test is never run. There's no way to run multiple independent test cases and get a report on all of them.

A dedicated testing framework solves all of these problems.


## Introducing Google Test


Google Test provides a structured environment for writing and running tests. It handles the boring parts for you so you can focus on the test logic itself. Its core value comes from two features:

1. **Test Macros**: It provides a set of assertion macros (`EXPECT_EQ`, `ASSERT_TRUE`, `EXPECT_NE`, etc.) that automatically handle the comparison, generate detailed failure messages, and allow test execution to continue even after a failure.
2. **Test Cases and** **`main()`**: It provides a `TEST()` macro to define independent, named test cases. It also provides its own `main()` function, so you don't have to write one. It finds all your `TEST()` cases, runs them, and produces a summary report.

Conceptually, our manual test can be replaced with a single, expressive line of `gtest` code:


```c++
EXPECT_EQ(
  get_greeting(),
  "Hello from the modular greeter library"
);
```


This is cleaner and far more readable.  Google Test also includes a suite of more advanced features to solve more complex testing requirements.  Let's integrate it into our project.


## Setup with vcpkg and CMake Presets


First, we need to add `gtest` as a dependency.  We'll use the [vcpkg version](https://vcpkg.io/en/package/gtest.html) in this example, but it's also available through [Conan](https://conan.io/center/recipes/gtest), and the source code is on the [official GitHub repository](https://github.com/google/googletest).


### Step 1: Update `vcpkg.json`


Let's add `"gtest"` to the `dependencies` array in `vcpkg.json` file at the project root.


<CodeFile path="vcpkg.json" status="Updated">


```json
{
  "name": "greeter",
  "dependencies": [
    "gtest"
  ]
}
```


</CodeFile>


### Step 2: Update CMake Presets


As always, to ensure `find_package()` can locate the `gtest` library installed by vcpkg, our CMake configuration needs to use the vcpkg toolchain file.


We'll handle this in the way we walked through in <InlineLessonPromo url="cmake/cmake-environment-variables-conditional-presets" title="Environment Variables and Conditional Presets" description="Learn to make your CMake presets portable by using environment variables and conditional logic to adapt to different machine configurations.">our earlier lesson on presets</InlineLessonPromo>.


We'll define a hidden `_base` preset that sets the `toolchainFile` for all other presets that inherit from it. This ensures our entire build workflow is vcpkg-aware. We'll read the path to our vcpkg installation from the `VCPKG_ROOT` environment variable:


<CodeFile path="CMakePresets.json" status="Updated">


```json
{
  "version": 3,
  "configurePresets": [{
    "name": "_base",
    "hidden": true,
    "binaryDir": "${sourceDir}/build",
    "toolchainFile":
      "$env{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake"
  }, {
    "name": "default",
    "displayName": "Default Config",
    "inherits": "_base"
  }],
  "buildPresets": [{
    "name": "default",
    "configurePreset": "default"
  }],
  "testPresets": [{
    "name": "default",
    "configurePreset": "default",
    "output": { "outputOnFailure": true }
  }]
}
```


</CodeFile>


Remember to set this `VCPKG_ROOT` environment variable if you haven't already, or update the `toolchainFile` argument with the hardcoded location of your vcpkg installation.


### Step 3: Update `tests/CMakeLists.txt`


Now, in `tests/CMakeLists.txt`, we can use `find_package()` to find `gtest`. Because our preset has configured the toolchain, this command should find the version installed by vcpkg.


We'll also delete the `add_test()` command, and implement `gtest`'s alternative approach soon:


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


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

find_package(GTest REQUIRED) #<h>

add_executable(GreeterTests main.cpp)
target_link_libraries(GreeterTests PRIVATE GreeterLib)

add_test(#<d>
  NAME Greeter.API.get_greeting#<d>
  COMMAND GreeterTests#<d>
)#<d>
```


</CodeFile>


The `find_package(GTest)` command does two important things:

1. It confirms that the `gtest` library is available.
2. It makes the imported targets `GTest::gtest` and `GTest::gtest_main`, and the command `gtest_discover_tests()` available.  We'll use all of these soon.

<Pw>


## Refactoring to a Google Test Case


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.


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


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

TEST(GreeterAPITests, GetGreetingReturnsCorrectString) {
  const std::string expected{
    "Hello from the modular greeter library"
  };
  
  EXPECT_EQ(get_greeting(), expected);
}
```


</CodeFile>


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


<CodeFile path="tests/CMakeLists.txt" 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        # The core gtest library //<h>
  GTest::gtest_main   # Provides a main() function //<h>
)
```


</CodeFile>

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

## Integrating with CTest


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:


<CodeFile path="tests/CMakeLists.txt" 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::gtest_main
)

gtest_discover_tests(GreeterTests)#<h>
```


</CodeFile>


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.


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


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


```c++
//<ti>
ctest --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.


```c++
//<o>
Test project D:/Projects/cmake/build
    Start 1: GreeterAPITests.GetGreetingReturnsCorrectString
1/1 Test #1: GreeterAPITests.GetGreetingReturnsCorrectString ...   Passed    0.01 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   0.02 sec
```


## Using Fixtures for Class-Based Testing


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.


<CodeViewer>


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


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

class Greeter {
public:
  std::string greet() const;
};
```


</CodeFile>


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


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

std::string Greeter::greet() const {
  return "Hello from the Greeter class!";
}
```


</CodeFile>


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


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

int main() {
  Greeter my_greeter;
  std::cout << my_greeter.greet();

  return 0;
}
```


</CodeFile>


</CodeViewer>


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.


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


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

TEST(GreeterClassTests, GreetReturnsCorrectString) {
  Greeter my_greeter; // Create an object//<h>
  EXPECT_EQ(
    my_greeter.greet(),//<h>
    "Hello from the Greeter class!"
  );
}
```


</CodeFile>


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:


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


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

// A test fixture for Greeter tests
class GreeterTest : public testing::Test {
protected:
  Greeter my_greeter;
};
```


</CodeFile>


 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.


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


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

class GreeterTest : public testing::Test {
protected:
  // This object will be created fresh for each TEST_F
  Greeter my_greeter;
};

// Use the TEST_F macro to use the fixture
TEST_F(GreeterTest, GreetReturnsCorrectString) {//<h>
  EXPECT_EQ(//<h>
    my_greeter.greet(),//<h>
    "Hello from the Greeter class!"//<h>
  );//<h>
}//<h>
```


</CodeFile>


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.


## Summary


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.

<Preview>


### Assertions, Parameterized Tests and Mocking


We've now mastered the fundamentals of setting up and running tests with `gtest` and CTest.


In the next lesson, we will explore more advanced testing topics. We'll learn:

- How to test more complex scenarios using different **assertion macros** and **custom matchers**
- How to test a function with hundreds of different argument combinations using **parameterized tests**,
- How to create "fake" versions of a function's dependencies using **mocking**, and why we'd want to

</Preview>


</Pw>

Advanced Unit Testing Topics

CMake Presets Fundamentals

GoogleTest User's Guide

gtest port

`FindGTest` Module Documentation

`gtest_discover_tests()` Command

GoogleTest GitHub Repository

A step-by-step guide to integrating Google Test (gtest) with CMake and vcpkg. Learn to replace manual tests with gtest macros, use test fixtures, and automate test discovery with gtest_discover_tests() for a modern C++ testing workflow.

CMake and Google Test Tutorial: C++ Unit Testing with vcpkg

Assertions, Parameterized Tests and Mocking

Integrating GoogleTest with CMake

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake