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 in this chapter, our tests have focused on our `GreeterLib`. Testing libraries is straightforward because they are designed to be linked against and used by other code, including our test executables.


But what about our `GreeterApp`? How do we test the code inside `main.cpp`? This presents a technical challenge: an executable target, by definition, has a `main()` function and is a final, standalone product. You cannot easily link one executable into another; one immediate problem is that we'd end up with two `main()` functions, which the linker would reject as a "multiple definition" error.


This lesson tackles this problem by introducing a standard refactoring pattern. We'll learn how to separate an application's core logic from its entry point, making the logic testable and the overall design more modular and robust.


## Organizing Tests for Scalability


As a project grows, so does its test code. A single `tests/main.cpp` file quickly becomes unmanageable. There are many ways to organize our tests, but one option is to structure our `tests/` directory to mirror our main project's source layout.


For our `Greeter` project, this would mean creating subdirectories for `app` and `greeter` within our `/tests` directory:


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


## Making Executables Testable


This structure immediately presents a new challenge. We want to write tests for the logic inside our `GreeterApp` executable, but how do you test a `main()` function?


An executable target cannot be linked into another target. It's a final product with a single entry point. Trying to link it into a test executable would create a conflict.


The solution is a refactoring pattern: **isolate the code you want to test into a linkable unit (a library).** This library can contain all the code that our executable needs.  The executable target then just becomes a thin wrapper - little more than a `main()` that calls a `run_app()` function defined in our library.


### Step 1: Create an Application Logic Library


We'll move the core logic of our application out of `main.cpp` and into a new library. Let's call it `GreeterAppLogic`.


First, let's create the source files for this new library.


<CodeViewer>


<CodeFile path="app/include/app/run.h" status="New">


```c++
#pragma once

// Declaration of the application's core logic
int run_app(int argc, char* argv[]);
```


</CodeFile>


<CodeFile path="app/src/run.cpp" status="New">


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

// The core logic is now in a testable function
int run_app(int argc, char* argv[]) {
  Greeter my_greeter;
  std::cout << my_greeter.greet();
  return 0;
}
```


</CodeFile>


</CodeViewer>


Our `main.cpp` now becomes a simple, untestable forwarder.


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


```c++
#include <app/run.h>

// The main function is just a thin entry point
int main(int argc, char* argv[]) {
  return run_app(argc, argv);
}
```


</CodeFile>


### Step 2: Update the App's CMakeLists.txt


Now, we update `app/CMakeLists.txt` to define this new two-part structure: a logic library and an executable that uses it.


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


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

# 1. The library containing the testable logic
add_library(GreeterAppLogic src/run.cpp)

target_link_libraries(GreeterAppLogic PRIVATE GreeterLib)

target_sources(GreeterAppLogic PUBLIC
  FILE_SET HEADERS
  BASE_DIRS "include"
  FILES "include/app/run.h"
)

# 2. The thin executable wrapper
add_executable(GreeterApp src/main.cpp)
target_link_libraries(GreeterApp PRIVATE GreeterAppLogic)
```


</CodeFile>


### Step 3: Update the Test CMakeLists.txt


With our logic now in a library, our test executable can link against it correctly.


First, the root `tests/CMakeLists.txt` becomes a simple dispatcher:


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


```c++
# This file just orchestrates the tests in subdirectories
add_subdirectory(greeter)
add_subdirectory(app)
```


</CodeFile>


The test for our `GreeterLib` remains mostly unchanged, just moved to its new location.  We've also renamed the target from `GreeterTests` to `GreeterLibTests` for clarity:


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


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


</CodeFile>


Finally, the new `GreeterAppTests` can link against `GreeterAppLogic`.


<CodeViewer>


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


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

add_executable(GreeterAppTests test_app.cpp)

# Link against the logic library, NOT the executable
target_link_libraries(GreeterAppTests PRIVATE
  GreeterAppLogic
  GTest::gtest
  GTest::gmock
  GTest::gmock_main
)

gtest_discover_tests(GreeterAppTests)
```


</CodeFile>


<CodeFile path="tests/app/test_app.cpp" status="New">


```c++
#include <gtest/gtest.h>
#include <app/run.h>

TEST(GreeterAppTests, RunsWithoutCrashing) {
  // We can now call the app's core logic directly
  EXPECT_EQ(run_app(0, nullptr), 0);
}
```


</CodeFile>


</CodeViewer>


With this structure, our test suite is now organized and easier to scale.  We should make sure our project still builds and runs as expected:


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


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


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


```c++
//<o>
Have a nice day! Hello from the Greeter class!
```


And that our existing library tests still pass, as well as our new app test:


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


```c++
//<o>
...
3/4 Test #3: DayOfWeekGreetings/GreeterDayTest.GreetsCorrectlyForDay
4/4 Test #4: GreeterAppTests.RunsWithoutCrashing

100% tests passed, 0 tests failed out of 4
```


<Aside>


### Using `ENABLE_EXPORTS`


CMake does make it possible to link against an executable target using the `ENABLE_EXPORTS` target property.  The [official documentation](https://cmake.org/cmake/help/latest/prop_tgt/ENABLE_EXPORTS.html) has more information.


However, this creates significant platform-specific complications and linking issues that are not easy to fix in a portable way.  Offloading the executable logic to a library is much more reliable and easier to work with.


</Aside>


<Pw>


## Test-Driven Development (TDD)


Test-Driven Development (TDD) is a process that flips the usual workflow on its head. Instead of writing production code and then writing tests for it, you write the tests **first**.  This has several advantages:

- **Drives Better Design**: Before you write a single line of implementation, you must first think as a **consumer** of your own code. What should the function be called? What arguments should it take? What should it return? Writing the test first forces you to design a friendly API from the outside in.
- **Creates Specifications**: A test is an unambiguous definition of what the production code must do to be considered "correct."  By considering and testing edge cases before writing the implementation, we build a clearer target to aim for, which helps us make better decisions on how the feature should be implemented.
- **It helps with development**: When we're writing our code, we now have the option of running the tests to see what our logic is doing.  This is often quicker than stepping through in a debugger or logging out results.
- **It tests the tests**: In complex scenarios, it's surprisingly easy to write tests that always pass, regardless of how the system is behaving.  If a test passes before you've written the implementation, you know the test itself is flawed.

### Practical Example: Adding Logging


Let's use TDD to add a new feature to our `GreeterApp`. The requirement is: when `run_app()` is executed, it should create a log file named `app_log.txt` and write a timestamped startup message to it.


### Write a Failing Test


First, we'll write a test in `tests/app/test_app.cpp` that assumes this feature already exists:


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


```c++
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <app/run.h>
#include <fstream>
#include <string>

class AppLogTest : public testing::Test {
protected:
  const std::string log_filename{"app_log.txt"};
};

TEST_F(AppLogTest, LogsStartupMessageToFile) {
  run_app(0, nullptr);

  std::ifstream log_file(log_filename);
  ASSERT_TRUE(log_file.is_open());

  std::string line;
  std::getline(log_file, line);

  // Use a matcher to check the format
  EXPECT_THAT(line, testing::HasSubstr(
    "App starting up"
  ));
}
```


</CodeFile>


Let's walk through the logic here:

- We use a test fixture in this example - `AppLogTest`.  This is not necessary for now - we could just use a regular test that includes the `app_log.txt` string - but we'll expand this file soon and the fixture will be useful.
- We create a <InlineLessonPromo url="pro-cpp/file-streams" title="File Streams" description="A detailed guide to reading and writing files in C++ using the standard library's `fstream` type">file stream</InlineLessonPromo> using `std::ifstream` to interact with the file.
- We first check if the file exists with the file stream's `is_open()` method.  We use `ASSERT` here to create a fatal error if the file doesn't exist, as there's no point in continuing in that scenario
- We use `std::getline()` to copy the first line from the stream into a `std::string` called `line`
- We expect that the `line` contains the substring "App starting up".  Our log file will have additional information too, such as the timestamp.  We can test for that using regex techniques (`testing::MatchesRegex` or `testing::ContainsRegex`) if preferred, but a simple check using `testing::HasSubstr` is good enough for this example

Note that this test might find a log file that was created in a **previous** test run.  This would mean our test would pass even though our current executable is broken and is no longer creating log files.  We'll fix this flaw later in the lesson.


If we build and run this test now, it will fail because `app_log.txt` isn't being created.  This failure is a good thing, as we haven't built that feature yet:


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


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


```c++
//<o>
Value of: log_file.is_open()
  Actual: false
Expected: true

[  FAILED  ] AppLogTest.LogsStartupMessageToFile (0 ms)
```


### Making the Test Pass


Now, we write the code in `app/src/run.cpp` to make the test pass. We'll add the `spdlog` dependency and the file logging logic.


First, let's update `vcpkg.json` to include `spdlog`:


<CodeFile path="vcpkg.json">


```json
{
  "name": "greeter",
  "dependencies": [
    "gtest",
    "spdlog"//<h>
  ]
}
```


</CodeFile>


We'll also update `app/CMakeLists.txt` to find and link `spdlog` to our logic library:


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


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

add_library(GreeterAppLogic src/run.cpp)
find_package(spdlog CONFIG REQUIRED)#<h>

target_link_libraries(GreeterAppLogic PRIVATE
  GreeterLib
  spdlog::spdlog#<h>
)

target_sources(GreeterAppLogic PUBLIC
  FILE_SET HEADERS
  BASE_DIRS "include"
  FILES "include/app/run.h"
)

add_executable(GreeterApp src/main.cpp)
target_link_libraries(GreeterApp PRIVATE GreeterAppLogic)
```


</CodeFile>


Now, let's add the logging code to `run_app()`.


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


```c++
#include <app/run.h>
#include <greeter/Greeter.h>
#include <iostream>
#include <spdlog/sinks/basic_file_sink.h>
#include <spdlog/spdlog.h>

int run_app(int argc, char* argv[]) {
  // Create a logger that writes to "app_log.txt"
  auto file_logger{
    spdlog::basic_logger_mt("app_logger", "app_log.txt")
  };
  spdlog::set_default_logger(file_logger);

  spdlog::info("App starting up");

  Greeter my_greeter;
  std::cout << my_greeter.greet();

  // Flush logs to ensure they're written
  spdlog::shutdown();
  return 0;
}
```


</CodeFile>


Finally, if we rebuild and run our tests, the `LogsStartupMessageToFile` test should pass.


```json
//<ti>
cmake --build --preset default
```


```json
//<ti>
ctest --default
```


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


## Test `SetUp()` and `TearDown()`


Previously, we saw how creating a fixture in the form of a class derived from `testing::Test` lets us share variables and functions that a collection of tests might need.


This may simply involve creating some member variables or, in more complex cases, we can add a constructor or override the inherited `SetUp()` method for logic that needs to run before every test that uses this fixture:


```c++
class AppLogTest : public testing::Test {
protected:
  const std::string log_filename{"app_log.txt"};

  void SetUp() override {//<h>
    // SetUp logic...//<h>
  }//<h>
};
```


We can extend this to have our tests clean up after themselves by implementing a destructor, or overriding the `TearDown()` method:


```c++
class AppLogTest : public testing::Test {
protected:
  const std::string log_filename{"app_log.txt"};

  void SetUp() override {
    // SetUp logic...
  }

  void TearDown() override {//<h>
    // TearDown logic...//<h>
  }//<h>
};
```


This is useful when our tests are creating long-lasting changes that may affect future tests.  Our test that calls `run_app()` is an example of this.  It creates a file on the filesystem, which will persist even after the test ends.


This is a problem because if, for example, we make a change that breaks our logging, our test might still pass.  It simply reads the log file from the previous run and assumes all is well.


Even if we clear out our build directory between each test run, this lingering file can still cause issues within a single test run.  For example, if we write a second test that runs our app in some different context and checks for the log file.  That log file may already exist from the other test, giving us unreliable reports.


Below, we write a new test that asserts that a log file exist, but doesn't actually do anything that would cause that log file to be created:


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


```c++
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <app/run.h>
#include <fstream>
#include <string>

class AppLogTest : public testing::Test {
protected:
  const std::string log_filename{"app_log.txt"};
};

//<c title="Previous Test (Unchanged)">
//<l>TEST_F(AppLogTest, LogsStartupMessageToFile) {/*...*/}
TEST_F(AppLogTest, LogsStartupMessageToFile) {
  run_app(0, nullptr);

  std::ifstream log_file(log_filename);
  ASSERT_TRUE(log_file.is_open());

  std::string line;
  std::getline(log_file, line);

  // Use a matcher to check the format
  EXPECT_THAT(line, testing::HasSubstr(
    "App starting up"
  ));
}
//</c>

TEST_F(AppLogTest, AnotherTest) {//<h>
  std::ifstream log_file(log_filename);//<h>
  //<h>
  // ...don't create a log file//<h>
  //<h>
  ASSERT_TRUE(log_file.is_open());//<h>
}//<h>
```


</CodeFile>


This test should fail but, if it runs after our existing test created that log file, it will incorrectly pass:


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


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


```c++
//<o>
5/5 Test #5: AppLogTest.AnotherTest ... Passed
100% tests passed, 0 tests failed out of 5
```


We can solve this by adding a `TearDown()` function to our fixture.  This will clean up any residual effects of tests using this fixture, ensuring each test is a discrete, self-contained unit:


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


```c++
#include <gmock/gmock.h>
#include <gtest/gtest.h>
#include <app/run.h>
#include <fstream>
#include <string>

class AppLogTest : public testing::Test {
protected:
  const std::string log_filename{"app_log.txt"};

  void TearDown() override {//<h>
    // Clean up the log file after each test//<h>
    std::remove(log_filename.c_str());//<h>
  }//<h>
};

//<c title="Previous Test (Unchanged)">
//<l>TEST_F(AppLogTest, LogsStartupMessageToFile) {/*...*/}
TEST_F(AppLogTest, LogsStartupMessageToFile) {
  run_app(0, nullptr);

  std::ifstream log_file(log_filename);
  ASSERT_TRUE(log_file.is_open());

  std::string line;
  std::getline(log_file, line);

  // Use a matcher to check the format
  EXPECT_THAT(line, testing::HasSubstr(
    "App starting up"
  ));
}
//</c>

//<c title="Previous Test (Unchanged)">
//<l>TEST_F(AppLogTest, AnotherTest) {/*...*/}
TEST_F(AppLogTest, AnotherTest) {
  std::ifstream log_file(log_filename);
  ASSERT_TRUE(log_file.is_open());
}
//</c>
```


</CodeFile>


Our `AnotherTest` should now reliably fail as expected:


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


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


```c++
//<o>
Value of: log_file.is_open()
  Actual: false
Expected: true

[  FAILED  ] AppLogTest.AnotherTest (0 ms)
```


## Summary


This lesson addressed the challenge of testing code that lives inside an executable. By applying a simple refactoring pattern, we made our application's logic fully testable.

- **The Problem**: Executable targets can't be linked against, making it impossible for a test executable to directly call functions defined in the application's main.cpp.
- **The Solution**: Isolate the application's core logic into its own library (`GreeterAppLogic`). The executable (`GreeterApp`) becomes a thin, untestable wrapper that simply calls a function from the logic library.
- **Testable by Design**: The test executable can then link against the new logic library, giving it full access to all the application's core functionality for testing.
- **TDD for Applications**: We saw how to write a failing test first and then implement the feature in the logic library to make it pass.
- **Test Isolation**: We used `gtest` fixtures with `SetUp()` and `TearDown()` methods to ensure our tests are isolated, cleaning up side effects like created files so that one test cannot influence another.

<Preview>


### Managing a Test Suite


We now know how to write sophisticated **individual** tests for both libraries and executables. 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

gcovr Documentation

Test Driven Development

Code coverage

Options for Debugging Your Program

Modern C++ Testing with Catch2 - Phil Nash

A practical CMake tutorial on how to test C++ executables. This lesson covers the refactoring pattern of separating application logic into a linkable library, making your main() function a thin wrapper, and allowing your Google Test suite to test the core functionality.

How to Test Executables in C++ with CMake and Google Test

Step 1: Create an Application Logic Library

Testing Executables

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake