TDD in C++: Test-Driven Development for Lazy Geniuses

Introduction: Why do we write bugs and then heroically fix them?

Have you ever written code that worked "sort of okay," only to find a bug three days later that broke everything? If yes — welcome to the club. If no — you are either a C++ god, or you just haven't deployed to production yet.

Test-Driven Development (TDD) is not a trendy diet for programmers. It is a discipline that turns the coding process upside down. Instead of writing the logic first and then frantically figuring out how to test it, we do the opposite: test first, then code. Sounds crazy? Maybe. But this is exactly how code is born that you're not ashamed to show your colleagues and that doesn't break on a Friday evening.

In this article, we'll break down TDD in C++ with real examples: we'll write a simple library for working with Fibonacci numbers using the Red-Green-Refactor cycle. You'll see how TDD helps not only to avoid bugs but also to design interfaces.

What is TDD and why is C++ without it like driving without brakes?

TDD (Test-Driven Development) is a development methodology where you first write a test that is expected to fail (Red), then write the minimal code to make the test pass (Green), and finally refactor (Refactor) to improve the structure without changing the behavior.

Why is this especially important for C++? Because C++ is a language where it's easy to shoot yourself in the foot: undefined behavior, memory leaks, incorrect type conversions. TDD automatically creates a safety net that catches errors at compile time and runtime.

The Red-Green-Refactor Cycle: How it works

\n
• Red: write a test that should fail. This is our "requirement" for the code.
\n
• Green: write the minimal code to make the test pass. No over-engineering!
\n
• Refactor: improve the code (remove duplication, simplify logic) — the tests remain green.
\n

Sounds simple? Yes. But in practice, it requires discipline. Let's try it.

Tools for TDD in C++: Google Test vs Catch2

Before writing code, let's choose a testing framework. Two main candidates:

\n
• Google Test — powerful, popular, with tons of macros. Great for large projects.
\n
• Catch2 — lightweight, modern, with convenient syntax. Ideal for tutorials and microservices.
\n

In this article, we'll use Catch2 (v3) because it's minimalistic and doesn't require extra setup. But if you prefer Google Test — the TDD principles are the same.

Practice: Writing TDD for Fibonacci Numbers

Let's imagine we need to write a function fibonacci(int n) that returns the n-th Fibonacci number (0th = 0, 1st = 1, 2nd = 1, 3rd = 2, etc.).

Step 1: Red — write a test that fails

Create a file test_fib.cpp:

#define CATCH_CONFIG_MAIN\n#include <catch2/catch_test_macros.hpp>\n\n// The function is not declared yet — that's fine\nint fibonacci(int n);\n\nTEST_CASE("Fibonacci numbers", "[fib]") {\n    REQUIRE(fibonacci(0) == 0);\n    REQUIRE(fibonacci(1) == 1);\n    REQUIRE(fibonacci(2) == 1);\n    REQUIRE(fibonacci(10) == 55);\n}

Try to compile — we get a linker error. The test is RED. Excellent!

Step 2: Green — write the minimal code to make the test pass

Create a file fib.cpp:

int fibonacci(int n) {\n    if (n <= 1) return n;\n    return fibonacci(n - 1) + fibonacci(n - 2);\n}

Compile and run the tests. Do they pass? Yes, but it's inefficient. However, our goal is Green, not perfection. We'll leave it as is for now.

Step 3: Refactor —