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

The last few lessons have equipped us with a powerful set of tools for writing individual tests. We can use GoogleTest for expressive assertions, mock dependencies to isolate our code, and create parameterized tests to cover a wide range of inputs.


This lesson takes the next logical step. Instead of focusing on **how** to write a single test, we'll learn how to manage, scale, and analyze an entire **test suite**. As a project grows from a handful of tests to hundreds or thousands, new challenges emerge:

- How do you run just a specific subset of tests to debug a feature?
- How do you speed up a test suite that's taking too long to run?
- How do you know what parts of your code are _not_ being tested?

We'll answer these questions by exploring advanced CTest features for organizing and running tests, and by introducing the concept of **code coverage analysis** to measure the effectiveness of our test suite.


## The Test Suite Structure


For this lesson, we'll use the project structure we developed in the <InlineLessonPromo url="cmake/cmake-testing-executables" title="Testing Executables" description="Learn the standard pattern for testing application logic by refactoring it into a linkable library">previous lesson</InlineLessonPromo>, where we have separate test executables for our application logic (`GreeterAppTests`) and our library (`GreeterLibTests`):


```plain text
//<nh>
Greeter/
├─ app/
├─ greeter/
└─ tests/
  ├─ app/
  │  ├─ CMakeLists.txt
  │  └─ test_app.cpp
  ├─ greeter/
  │  ├─ CMakeLists.txt
  │  └─ test_greeter.cpp
  └─ CMakeLists.txt
```


The root `CMakeLists.txt` enables testing and adds the test subdirectories, while each component's test directory builds a test executable and uses `gtest_discover_tests()` to register its tests.


## Advanced CTest Features


As our test suite grows, running `ctest` by itself becomes inefficient. We need ways to select, organize, and accelerate our tests.


### Filtering Tests


Sometimes you're working on a specific feature and only want to run the tests related to it. CTest provides two primary flags for this, which can be combined.

- `-R <regex>` or `--tests-regex <regex>`: **R**un only the tests whose names match the given regular expression.
- `-E <regex>` or `--exclude-regex <regex>`: **E**xclude tests whose names match the regex.

To run only the tests for our log file creation (which all have `AppLogTest` in their name as they use that fixture class), we could use the following command from our **build** directory:


```c++
//<ti>
ctest -R AppLogTest
```


```javascript
//<o>
1/1 Test #4: AppLogTest.LogsStartupMessageToFile ...   Passed
100% tests passed, 0 tests failed out of 1
```


To run all tests **except** those, we'd use `-E`:


```c++
//<ti>
ctest -E AppLogTest
```


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


This is useful, but relying on naming conventions can be brittle. A better way to group tests is with labels.


### Grouping with Labels


Labels are tags you can attach to a group of tests. The main way we label tests managed by `gtest` is to pass additional arguments to the `gtest_discover_test()` command.


In the following example, we attach the "library" label to all tests found for our `GreeterLibTests` target:


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


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

add_executable(GreeterLibTests test_greeter.cpp)

target_link_libraries(GreeterLibTests PRIVATE
  GreeterLib
  GTest::gtest
  GTest::gmock
  GTest::gmock_main
)

gtest_discover_tests(GreeterLibTests
  # Label all discovered tests as library tests
  PROPERTIES LABELS "library"
)
```


</CodeFile>


And similarly, for application tests:


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


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

add_executable(GreeterAppTests test_app.cpp)

target_link_libraries(GreeterAppTests PRIVATE
  GreeterAppLogic
  GTest::gtest_main
)

gtest_discover_tests(GreeterAppTests
  # Label all discovered tests as application tests
  PROPERTIES LABELS "application"
)
```


</CodeFile>


Now, after re-building, we can use the `-L <label>` flag to run tests by group. To run all application-level tests, we'd use this command from our **build** directory:


```c++
//<ti>
ctest -L application
```


```javascript
//<o>
...
100% tests passed, 0 tests failed out of 1
```


You can even combine labels with regexes for more complex filtering.


### Parallel Execution


As the number of test executables grows, the total run time can become a bottleneck. CTest can run your test **programs** in parallel to speed things up. The `-j <N>` flag tells CTest to use up to `N` parallel **jobs**.


This command will run up to 8 test executables simultaneously:


```c++
//<ti>
ctest -j8
```


```javascript
//<o>
...
100% tests passed, 0 tests failed out of 4

Label Time Summary:
application    =   0.02 sec*proc (1 test)
library        =   0.03 sec*proc (3 tests)

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


Even though our application tests took `0.02` seconds and our library tests took `0.03` seconds, they were run concurrently, so the entire suite completed in `0.03` seconds.


<Aside>


### Test Parallelism vs. Thread Parallelism


It's important to understand that `ctest -j` parallelizes at the level of **test executables**. If you have one giant test executable with 1000 tests inside it, `ctest -j8` will still only run one process.


To get the benefit of parallel execution, you should structure your tests into multiple, independent test executables (e.g., one per library or major component), as we have done in our project.


</Aside>


### Debugging Failures


When a test fails, `ctest` gives you some helpful options.

- `--output-on-failure`: We've seen this before. It prints the stdout/stderr of any failing test. This is essential for debugging.
- `--rerun-failed`: This is a huge time-saver. After a test run where some tests failed, this command will re-run _only_ the tests that previously failed, ignoring all the ones that passed.  This is useful if we think we've fixed the failing tests, and want to get a quick verification.

<Pw>


## Test Presets


As these command lines get longer, it's a good idea to encapsulate them in presets. We can create presets for running specific test groups and for debugging.


Below, we update our `default` test preset to use 8 parallel jobs.  We also add `app-tests` and `lib-tests` presets that `inherits` from `default` to apply filtering based on our labels:


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


```json
{
  "version": 3,
  "configurePresets": [{
    "name": "default",
    "hidden": true,
    "binaryDir": "${sourceDir}/build",
    "toolchainFile":
      "$env{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake"
  }],
  "buildPresets": [{
    "name": "default",
    "configurePreset": "default"
  }],
  "testPresets": [{
    "name": "default",
    "configurePreset": "default",
    "output": { "outputOnFailure": true },
    "execution": { "jobs": 8 }//<h>
  }, {//<h>
    "name": "app-tests",//<h>
    "inherits": "default",//<h>
    "filter": { "include": { "label": "application" } }//<h>
  }, {//<h>
    "name": "lib-tests",//<h>
    "inherits": "default",//<h>
    "filter": { "include": { "label": "library" } }//<h>
  }]//<h>
}
```


</CodeFile>


Now, we can easily run a subset of our tests from our project root:


```c++
//<ti>
ctest --preset app-tests
```


```javascript
//<o>
...
100% tests passed, 0 tests failed out of 1
```


## Code Coverage Analysis


Our tests confirm that the code we've written works as expected. But they don't tell us what we've missed. **Code coverage** is a metric that answers the question: "which parts of my production code were executed by my test suite?"


### How it Works

1. **Instrumentation**: You compile your code with special compiler flags that add "instrumentation". This extra code keeps track of which lines are executed and how many times.
2. **Execution**: You run your test suite. As the tests run, the instrumentation writes raw coverage data to files on disk.
3. **Reporting**: You use a separate tool to read these raw data files and generate a human-readable report (usually HTML) that visualizes the coverage.

### Step 1: Setting Up CMake for Coverage


We need to add the instrumentation flags. For GCC and Clang, the flags are `--coverage`.


Since we only want this for a special coverage build, we'll create a new `Coverage` build type and use a generator expression to apply the flags.


We can implement on a target-by-target basis with commands like `target_compile_options()` and `target_link_options()` that we covered previously.  Or, alternatively, we could implement it globally using `add_compile_options()` and `add_link_options()`:


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


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

# Add coverage flags for GCC/Clang in the "Coverage" build type
set(COVERAGE_CONDITION#<h>
  "$<AND:$<CONFIG:Coverage>,$<CXX_COMPILER_ID:GNU,Clang>>"#<h>
)#<h>
set(COVERAGE_FLAGS "$<${COVERAGE_CONDITION}:--coverage>")#<h>
add_compile_options(${COVERAGE_FLAGS})#<h>
add_link_options(${COVERAGE_FLAGS})#<h>

add_subdirectory(app)
add_subdirectory(greeter)

enable_testing()
add_subdirectory(tests)
```


</CodeFile>


And we'll add corresponding presets to our `CMakePresets.json`:


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


```json
{
  "version": 3,
  "configurePresets": [
    // ...
    {
      "name": "coverage",
      "displayName": "Coverage Build",
      "inherits": "default",
      "cacheVariables": { "CMAKE_BUILD_TYPE": "Coverage" }
    }
  ],
  "buildPresets": [
    // ...
    {
      "name": "coverage",
      "configurePreset": "coverage"
    }
  ],
  "testPresets": [
    // ...
    {
      "name": "coverage",
      "inherits": "default",
      "configurePreset": "coverage"
    }
  ]
}
```


</CodeFile>


### Step 2: Generating Coverage Data


Now, we follow the usual three step process from our project root:


```javascript
//<ti>
cmake --preset=coverage
```


```javascript
//<ti>
cmake --build --preset=coverage
```


```javascript
//<ti>
ctest --preset=coverage
```


After running `ctest`, our build directory will be populated with `.gcno` and `.gcda` files containing the raw coverage data.  On Unix-like systems, we can confirm our coverage data is being generated using a command like this:


```javascript
//<ti>
find build/ -name "*.gcda" -o -name "*.gcno"
```


```javascript
//<o>
build/app/CMakeFiles/GreeterApp.dir/src/main.cpp.gcno
build/app/CMakeFiles/GreeterAppLogic.dir/src/run.cpp.gcda
build/app/CMakeFiles/GreeterAppLogic.dir/src/run.cpp.gcno
...
```


We can get similar output using the `dir` command on PowerShell:


```javascript
//<ti>
dir build -Recurse -Include "*.gcda", "*.gcno"
```


## Using `gcovr`


To turn this raw data into a useful report, we need a tool. There are several options here, but a Python-based tool called `gcovr` is quite common.


`gcovr` is only available as a Python package, so we must have Python installed on our system.  Then, we can install it using `pip`:


```c++
//<ti>
pip install gcovr
```


Then, from our root directory, we can generate the report:


```c++
//<ti>
gcovr -r . \
  --filter 'greeter/' \
  --filter 'app/' \
  --html 'build/coverage.html'
```

- `r .`: Sets the root of your source tree to the current directory
- `--filter`: Sets what paths should be included in the report
- `-html`: Specifies the HTML output file

If we open our `/build/coverage.html` report in a web browser, we'll how much of our code the tests are covering:


<Img file="gcovr-report.png" alt="Screenshot showing the code coverage report" width="993" height="373" blurHash="LNQ0gex_n5XQ~XaISvw~~pjExuW:" />


In our case, the tests are hitting every line of code aside from our `main.cpp`, which only includes the `main()` entry point after our recent updates.


However, it's important to note that just because a line of code is being executed in the process of running a test, that doesn't necessarily mean that the code is being tested in any meaningful way.


Coverage reports just give us a relatively simple way to discover which parts of our code **definitely aren't being tested**, because they're not even being executed by our suite.


### Branch Coverage


Whilst our tests execute every line of our library code, the coverage report will show that they don't execute every **branch**.


Even very simple statements can include hidden branching behavior, such as this line in our library:


```javascript
day_str = "Happy Monday!";
```


This is because the `std::string`'s `=` operator can throw an **exception** if, for example, memory-related limitations prevent the assignment.  This would result in a `std::bad_alloc` or `std::length_error` exception.


The branch coverage section of our report tells us that our tests did not create that scenario.  In this case, the code in our library also isn't considering this possibility.


Our production could be updated with <InlineLessonPromo url="pro-cpp/throw-try-catch" title="Exceptions: `throw`, `try` and `catch`" description="This lesson provides an introduction to exceptions, detailing the use of `throw`, `try`, and `catch`.">try-catch blocks</InlineLessonPromo> to handle exceptions.  Our test code could then create these exceptions by using the <InlineLessonPromo url="cmake/google-mock" title="Dependency Injection and Mocking" description="Learn how to isolate dependencies that our project uses, and then how to replace those dependencies at test time using Google Mock.">mocking techniques</InlineLessonPromo> we covered previously.


## Automating Report Generation


We can use all the techniques we covered earlier, such as <InlineLessonPromo url="cmake/cmake-custom-commands" title="Integrating Tools with `add_custom_command()`" description="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.">custom commands</InlineLessonPromo> or <InlineLessonPromo url="cmake/custom-targets-and-build-utilities" title="Custom Targets and Build Utilities" description="Learn to create standalone, non-code targets using add_custom_target() for utility tasks like code formatting and documentation generation.">custom targets</InlineLessonPromo> to automate processes such as generating coverage reports.


For example, the following code creates a custom `coverage` target that lets us invoke `gcovr` without needing to provide the arguments:


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


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

set(COVERAGE_CONDITION
  "$<AND:$<CONFIG:Coverage>,$<CXX_COMPILER_ID:GNU,Clang>>"
)
set(COVERAGE_FLAGS "$<${COVERAGE_CONDITION}:--coverage>")
add_compile_options(${COVERAGE_FLAGS})
add_link_options(${COVERAGE_FLAGS})

find_program(GCOVR_EXE gcovr)#<h>
if(GCOVR_EXE)#<h>
  add_custom_target(coverage#<h>
    COMMAND ${GCOVR_EXE}#<h>
      -r "${CMAKE_SOURCE_DIR}"#<h>
      --filter "${CMAKE_SOURCE_DIR}/greeter/"#<h>
      --filter "${CMAKE_SOURCE_DIR}/app/"#<h>
      --html "coverage.html"#<h>
    COMMENT "Generating code coverage report..."#<h>
  )#<h>
  message(STATUS "Added 'coverage' target")#<h>
endif()#<h>

add_subdirectory(app)
add_subdirectory(greeter)

enable_testing()
add_subdirectory(tests)
```


</CodeFile>


Now, after running our tests in a coverage build, we can generate the report with a simple command from the `build/` directory:


```c++
//<ti>
cmake --build . --target coverage
```


Remember, we can (and should) keep our root `CMakeLists.txt` file as clean as possible by moving capabilities out to <InlineLessonPromo url="cmake/modularizing-cmake-code" title="Modularizing CMake Code" description="Learn to create reusable logic with CMake functions and macros, and how to organize them into modules for clean, scalable build systems.">module files</InlineLessonPromo> when things get too noisy:


<CodeViewer>


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


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

include(cmake/Coverage.cmake)#<h>

add_subdirectory(app)
add_subdirectory(greeter)

enable_testing()
add_subdirectory(tests)
```


</CodeFile>


<CodeFile path="cmake/Coverage.cmake" status="New">


```c++
#<cmake>
set(COVERAGE_CONDITION
  "$<AND:$<CONFIG:Coverage>,$<CXX_COMPILER_ID:GNU,Clang>>"
)
set(COVERAGE_FLAGS "$<${COVERAGE_CONDITION}:--coverage>")
add_compile_options(${COVERAGE_FLAGS})
add_link_options(${COVERAGE_FLAGS})

find_program(GCOVR_EXE gcovr)

if(GCOVR_EXE)
  add_custom_target(coverage
    COMMAND ${GCOVR_EXE}
      -r "${CMAKE_SOURCE_DIR}"
      --filter "${CMAKE_SOURCE_DIR}/greeter/"
      --filter "${CMAKE_SOURCE_DIR}/app/"
      --html "coverage.html"
    COMMENT "Generating code coverage report..."
  )
  message(STATUS "Added 'coverage' target")
endif()
```


</CodeFile>


</CodeViewer>


## Summary


This lesson improved our testing from writing individual checks to managing a complete test suite.

- **Suite Management**: We used CTest's filtering (`-R`, `-E`) and labeling (`-L`) capabilities for fine-grained control, and ran tests in parallel (`-j`) for speed. Presets allow us to encapsulate these complex commands into simple, named workflows.
- **Code Coverage**: We learned how to instrument our code with `--coverage` flags and use `gcovr` to generate reports that show where the gaps in our testing are.
- **Automation**: By creating custom targets for tasks like coverage analysis, we can integrate these workflows into our build process, and automate them.

<Preview>


### Other Automated Analysis and Checks


We now have a suite of tests to verify our code's **functional correctness**. But correctness is only one aspect of software quality. Is our code free of memory errors? Is it performant? Does it adhere to best practices?


In the next chapter, we will explore other forms of automated analysis. We'll learn how to integrate tools like **AddressSanitizer** for memory error detection, **Google Benchmark** for performance testing, and **Clang-Tidy** for static analysis.


</Preview>


</Pw>

Google Test Integration with vcpkg

gcovr Documentation

Test Driven Development

Code coverage

Options for Debugging Your Program

Modern C++ Testing with Catch2 - Phil Nash

CTest Documentation

set_tests_properties() Command

A comprehensive tutorial on advanced C++ testing with CMake and CTest. Learn how to organize your test suite, run tests in parallel, filter by labels, and perform code coverage analysis with gcovr for robust, high-quality software.

Managing a Test Suite

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake