C++-Testen (Agent-Kompetenz)

Agentenorientierter Test-Workflow für modernes C++ (C++17/20) unter Verwendung von GoogleTest/GoogleMock mit CMake/CTest.

Anwendungsfälle

• Beim Erstellen neuer C++-Tests oder beim Korrigieren bestehender Tests
• Entwurf der Unit-/Integrationstestabdeckung für C++-Komponenten
• Erweiterung der Testabdeckung, CI-Gating oder Regressionsschutz
• Konfiguration von CMake/CTest-Workflows für eine konsistente Ausführung
• Untersuchung von Testfehlern oder unvorhersehbarem Verhalten
• Aktivieren von Sanitizern für Speicher- und Race-Diagnosen

Wann sollte man es NICHT verwenden?

• Implementierung neuer Produktfunktionen ohne Änderungen an den Tests
• Umfangreiche Refactorings, die nicht mit der Testabdeckung oder Testfehlern zusammenhängen
• Leistungsoptimierung ohne zu validierende Testregressionen
• Nicht-C++-Projekte oder Aufgaben, die nicht mit Tests zusammenhängen

Kernkonzepte

• TDD-Zyklus: rot → grün → Refactoring (zuerst Tests, minimale Korrektur, dann Bereinigung).
• Isolation: Bevorzugen Sie Dependency Injection und Fakes gegenüber globalem Zustand.
• Testlayout: tests/unit, tests/integration, tests/testdata.
• Mocks vs. Fakes: Mocks für Interaktionen, Fakes für zustandsbehaftetes Verhalten.
• CTest-Erkennung: Verwenden Sie gtest_discover_tests() für stabile Testerkennung.
• CI-Signal: Führen Sie zuerst eine Teilmenge aus, dann die vollständige Testsuite mit --output-on-failure.

TDD-Workflow

Befolgen Sie den RED → GREEN → REFACTOR-Zyklus:

1. ROT: Schreiben Sie einen fehlgeschlagenen Test, der das neue Verhalten erfasst
2. GRÜN: Die kleinste Änderung implementieren, damit der Test besteht
3. REFACTOR: Bereinigen, solange die Tests grün bleiben

// tests/add_test.cpp
#include 

int Add(int a, int b); // Provided by production code.

TEST(AddTest, AddsTwoNumbers) { // RED
  EXPECT_EQ(Add(2, 3), 5);
}

// src/add.cpp
int Add(int a, int b) { // GREEN
  return a + b;
}

// REFACTOR: simplify/rename once tests pass

Code-Beispiele

Einfacher Unit-Test (gtest)

// tests/calculator_test.cpp
#include 

int Add(int a, int b); // Provided by production code.

TEST(CalculatorTest, AddsTwoNumbers) {
    EXPECT_EQ(Add(2, 3), 5);
}

Fixture (gtest)

// tests/user_store_test.cpp
// Pseudocode stub: replace UserStore/User with project types.
#include 
#include 
#include 
#include 

struct User { std::string name; };
class UserStore {
public:
    explicit UserStore(std::string /*path*/) {}
    void Seed(std::initializer_list /*users*/) {}
    std::optional Find(const std::string &/*name*/) { return User{"alice"}; }
};

class UserStoreTest : public ::testing::Test {
protected:
    void SetUp() override {
        store = std::make_unique(":memory:");
        store->Seed({{"alice"}, {"bob"}});
    }

    std::unique_ptr store;
};

TEST_F(UserStoreTest, FindsExistingUser) {
    auto user = store->Find("alice");
    ASSERT_TRUE(user.has_value());
    EXPECT_EQ(user->name, "alice");
}

Mock (gmock)

// tests/notifier_test.cpp
#include 
#include 
#include 

class Notifier {
public:
    virtual ~Notifier() = default;
    virtual void Send(const std::string &message) = 0;
};

class MockNotifier : public Notifier {
public:
    MOCK_METHOD(void, Send, (const std::string &message), (override));
};

class Service {
public:
    explicit Service(Notifier ¬ifier) : notifier_(notifier) {}
    void Publish(const std::string &message) { notifier_.Send(message); }

private:
    Notifier ¬ifier_;
};

TEST(ServiceTest, SendsNotifications) {
    MockNotifier notifier;
    Service service(notifier);

    EXPECT_CALL(notifier, Send("hello")).Times(1);
    service.Publish("hello");
}

CMake/CTest-Schnellstart

# CMakeLists.txt (excerpt)
cmake_minimum_required(VERSION 3.20)
project(example LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

include(FetchContent)
# Prefer project-locked versions. If using a tag, use a pinned version per project policy.
set(GTEST_VERSION v1.17.0) # Adjust to project policy.
FetchContent_Declare(
  googletest
  # Google Test framework (official repository)
  URL https://github.com/google/googletest/archive/refs/tags/${GTEST_VERSION}.zip
)
FetchContent_MakeAvailable(googletest)

add_executable(example_tests
  tests/calculator_test.cpp
  src/calculator.cpp
)
target_link_libraries(example_tests GTest::gtest GTest::gmock GTest::gtest_main)

enable_testing()
include(GoogleTest)
gtest_discover_tests(example_tests)

cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build -j
ctest --test-dir build --output-on-failure

Tests ausführen

ctest --test-dir build --output-on-failure
ctest --test-dir build -R ClampTest
ctest --test-dir build -R "UserStoreTest.*" --output-on-failure

./build/example_tests --gtest_filter=ClampTest.*
./build/example_tests --gtest_filter=UserStoreTest.FindsExistingUser

Fehler beheben

1. Führen Sie den einzelnen fehlgeschlagenen Test mit dem gtest-Filter erneut aus.
2. Fügen Sie um die fehlgeschlagene Assertion herum eine bereichsbezogene Protokollierung hinzu.
3. Führen Sie den Test erneut aus, wobei die Sanitizer aktiviert sind.
4. Erweitern Sie die Testsuite auf den vollen Umfang, sobald die Grundursache behoben ist.

Abdeckung

Bevorzugen Sie Einstellungen auf Zielebene anstelle von globalen Flags.

option(ENABLE_COVERAGE "Enable coverage flags" OFF)

if(ENABLE_COVERAGE)
  if(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
    target_compile_options(example_tests PRIVATE --coverage)
    target_link_options(example_tests PRIVATE --coverage)
  elseif(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
    target_compile_options(example_tests PRIVATE -fprofile-instr-generate -fcoverage-mapping)
    target_link_options(example_tests PRIVATE -fprofile-instr-generate)
  endif()
endif()

GCC + gcov + lcov:

cmake -S . -B build-cov -DENABLE_COVERAGE=ON
cmake --build build-cov -j
ctest --test-dir build-cov
lcov --capture --directory build-cov --output-file coverage.info
lcov --remove coverage.info '/usr/*' --output-file coverage.info
genhtml coverage.info --output-directory coverage

Clang + llvm-cov:

cmake -S . -B build-llvm -DENABLE_COVERAGE=ON -DCMAKE_CXX_COMPILER=clang++
cmake --build build-llvm -j
LLVM_PROFILE_FILE="build-llvm/default.profraw" ctest --test-dir build-llvm
llvm-profdata merge -sparse build-llvm/default.profraw -o build-llvm/default.profdata
llvm-cov report build-llvm/example_tests -instr-profile=build-llvm/default.profdata

Sanitizer

option(ENABLE_ASAN "Enable AddressSanitizer" OFF)
option(ENABLE_UBSAN "Enable UndefinedBehaviorSanitizer" OFF)
option(ENABLE_TSAN "Enable ThreadSanitizer" OFF)

if(ENABLE_ASAN)
  add_compile_options(-fsanitize=address -fno-omit-frame-pointer)
  add_link_options(-fsanitize=address)
endif()
if(ENABLE_UBSAN)
  add_compile_options(-fsanitize=undefined -fno-omit-frame-pointer)
  add_link_options(-fsanitize=undefined)
endif()
if(ENABLE_TSAN)
  add_compile_options(-fsanitize=thread)
  add_link_options(-fsanitize=thread)
endif()

Unzuverlässige Tests Schutzmaßnahmen

• Verwenden Sie niemals sleep zur Synchronisation; verwende stattdessen Bedingungsvariablen oder Latches.
• Legen Sie für jeden Test ein eigenes temporäres Verzeichnis an und löschen Sie diese stets.
• Vermeiden Sie Echtzeit-, Netzwerk- oder Dateisystemabhängigkeiten in Unit-Tests.
• Verwenden Sie deterministische Startwerte für zufällige Eingaben.

Bewährte Vorgehensweisen

TUN

• Halten Sie Tests deterministisch und isoliert
• Bevorzugen Sie Dependency Injection gegenüber globalen Variablen
• Verwenden Sie ASSERT_* für Vorbedingungen, EXPECT_* für mehrere Prüfungen
• Trennen Sie Unit- und Integrationstests in CTest-Labels oder Verzeichnissen
• Führen Sie in der CI Sanitizer zur Speicher- und Race-Erkennung aus

NICHT

• Verlassen Sie sich in Unit-Tests nicht auf Echtzeit oder das Netzwerk
• Verwenden Sie keine „sleep“-Anweisungen zur Synchronisation, wenn eine Bedingungsvariable verwendet werden kann
• Verwenden Sie kein übermäßiges Mocking für einfache Wert-Objekte
• Verwenden Sie keine instabile String-Übereinstimmung für unkritische Protokolle

Häufige Fallstricke

• Verwendung fester temporärer Pfade → Generieren Sie pro Test eindeutige temporäre Verzeichnisse und löschen Sie diese anschließend.
• Verlassen Sie sich nicht auf die Wanduhrzeit → Fügen Sie eine Uhr ein oder verwenden Sie gefälschte Zeitquellen.
• Unzuverlässige Parallelitätstests → Verwende Bedingungsvariablen/Latches und begrenzte Wartezeiten.
• Versteckter globaler Zustand → Setzen Sie den globalen Zustand in Fixtures zurück oder entfernen Sie globale Variablen.
• Übermäßiges Mocking → Bevorzugen Sie Fakes für zustandsbehaftetes Verhalten und simulieren Sie nur Interaktionen.
• Fehlende Sanitizer-Läufe → ASan-/UBSan-/TSan-Builds in die CI einbinden.
• Abdeckung bei reinen Debug-Builds → Sicherstellen, dass Abdeckungsziele konsistente Flags verwenden.

Optionaler Anhang: Fuzzing / Eigenschaftstests

Nur verwenden, wenn das Projekt bereits LLVM/libFuzzer oder eine Bibliothek für das Property-Testing unterstützt.

• libFuzzer: am besten geeignet für reine Funktionen mit minimalem E/A-Aufwand.
• RapidCheck: Eigenschaftsbasierte Tests zur Validierung von Invarianten.

Minimales libFuzzer-Harness (Pseudocode: „ParseConfig“ ersetzen):

#include 
#include 
#include 

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    std::string input(reinterpret_cast(data), size);
    // ParseConfig(input); // project function
    return 0;
}

Alternativen zu GoogleTest

• Catch2: Nur-Header, ausdrucksstarke Matcher
• doctest: schlank, minimaler Kompilierungsaufwand