E2E-Tests von C++-Anwendungen: von der Theorie bis zum produktiven CI/CD

Warum „nur Unit-Tests“ nicht mehr ausreichen?

Sie haben perfekten C++-Code geschrieben. Die Kompilierung war erfolgreich, die Unit-Tests sind grün, das Code-Review wurde genehmigt. Sie bringen ein Release heraus – und eine Stunde später beschweren sich die Benutzer: „Der Button funktioniert nicht“, „Die Datenbank antwortet nicht“, „Die GUI hängt“. Kommt Ihnen das bekannt vor?

Das Problem ist, dass Unit-Tests eine Funktion prüfen, aber kein Szenario. Sie sind isoliert. In der realen Welt interagiert Ihr C++-Code jedoch mit dem Netzwerk, dem Dateisystem, der GPU, externen APIs und anderen Threads. Genau hier kommen E2E-Tests von C++-Anwendungen (End-to-End- oder durchgängige Tests) ins Spiel.

In diesem Artikel werden wir uns ansehen, wie man das Chaos von Integrationsfehlern in ein strukturiertes System automatischer Überprüfungen verwandelt. Sie erfahren, welche Werkzeuge wirklich funktionieren, wie man Tests schreibt, die beim ersten Start nicht auseinanderfallen, und wie man E2E in die CI/CD-Pipeline integriert. Los geht's!

Was ist E2E-Testing im Kontext von C++?

E2E-Testing ist die Überprüfung eines vollständigen Benutzerszenarios „von Anfang bis Ende“. Im Gegensatz zu Modultests, die eine einzelne Funktion prüfen, startet ein E2E-Test Ihre Anwendung (oder einen kritischen Teil davon) in einer Umgebung, die der Produktion so nahe wie möglich kommt.

Für C++ kann dies bedeuten:

\n
• Desktop-Anwendung: Starten eines Fensters, Klicken auf die Schaltfläche „Senden“, Überprüfen, ob die Daten in der Datenbank gelandet sind.
\n
• Serveranwendung: Senden einer HTTP-Anfrage an Ihre REST-API, Überprüfen der Antwort und des Datenbankzustands.
\n
• Embedded/Software: Anlegen eines Signals am Eingang, Überprüfen des Ausgangssignals nach einer bestimmten Zeit.
\n

Der entscheidende Unterschied ist die reale Umgebung. Keine Mock-Objekte für Datenbank oder Netzwerk. Nur echte Hardware (oder Docker).

Werkzeugkasten: Was funktioniert 2024 wirklich für C++?

Kommen wir direkt zur Sache. Hier ist der Stack, den wir im Einsatz verwenden:

\n
• Catch2 oder Google Test – zum Schreiben der Teststruktur (Arrange-Act-Assert).
\n
• Docker – zum Bereitstellen einer sauberen Umgebung (DB, Warteschlangen, Abhängigkeiten).
\n
• Pytest + subprocess – zur Orchestrierung (ja, Python, aber es ist ideal zum Verkleben von C++-Binärdateien).
\n
• Selenium/Appium – wenn Sie eine GUI mit Qt oder WebView haben.
\n
• CMake + CTest – zum Ausführen von Tests und Sammeln von Ergebnissen.
\n

Versuchen Sie nicht, E2E-Tests nur in C++ zu schreiben. Das ist schmerzhaft. Verwenden Sie Python als Kleber – es ist schneller für Integrationsszenarien.

Praxis: Schreiben eines E2E-Tests für eine REST-API in C++

Angenommen, wir haben einen C++-Server mit cpp-httplib (oder crow, oder drogon). Er akzeptiert POST-Anfragen unter /api/user und speichert den Benutzer in PostgreSQL.

Schreiben wir einen E2E-Test, der:

\n
1. Einen Docker-Container mit PostgreSQL hochfährt.
\n
2. Unseren Server kompiliert und startet.
\n
3. Eine HTTP-Anfrage über curl (oder einen C++-Client) sendet.
\n
4. Überprüft, ob der Benutzer in der Datenbank erscheint.
\n

Schritt 1: Docker-compose für die Testumgebung

version: '3.8'\nservices:\n  db:\n    image: postgres:15\n    environment:\n      POSTGRES_DB: testdb\n      POSTGRES_USER: testuser\n      POSTGRES_PASSWORD: testpass\n    ports:\n      - "5432:5432"\n  app:\n    build: .\n    depends_on:\n      - db\n    ports:\n      - "8080:8080"\n    environment:\n      DB_HOST: db\n

Schritt 2: Test in C++ mit Catch2

// test_e2e_api.cpp\n#include <catch2/catch_test_macros.hpp>\n#include <httplib.h>\n#include <nlohmann/json.hpp>\n#include <cstdlib>\n\nTEST_CASE("E2E: Create user via API and verify in DB") {\n    // Arrange\n    httplib::Client cli("localhost", 8080);\n    nlohmann::json user = {\n        {"name", "John Doe"}