Tests E2E d'applications C++ : de la théorie au CI/CD opérationnel

Pourquoi « les simples tests unitaires » ne suffisent-ils plus ?

Vous avez écrit un code C++ parfait. La compilation s'est déroulée sans erreur, les tests unitaires sont verts, la revue de code a été approuvée. Vous publiez la version — et une heure plus tard, les utilisateurs se plaignent : « le bouton ne répond pas », « la base de données ne répond pas », « l'interface graphique se fige ». Cela vous dit quelque chose ?

Le problème est que les tests unitaires vérifient une fonction, mais pas un scénario. Ils sont isolés. Or, dans le monde réel, votre code C++ interagit avec le réseau, le système de fichiers, le GPU, des API externes et d'autres threads. C'est là qu'interviennent les tests E2E d'applications C++ (End-to-End ou tests de bout en bout).

Dans cet article, nous allons voir comment transformer le chaos des erreurs d'intégration en un système structuré de vérifications automatiques. Vous découvrirez quels outils fonctionnent réellement, comment écrire des tests qui ne s'effondreront pas au premier lancement, et comment intégrer les tests E2E dans un pipeline CI/CD. C'est parti !

Qu'est-ce que le test E2E dans le contexte du C++ ?

Le test E2E est la vérification d'un scénario utilisateur complet « du début à la fin ». Contrairement aux tests unitaires qui vérifient une fonction spécifique, un test E2E lance votre application (ou sa partie critique) dans un environnement aussi proche que possible de la production.

Pour le C++, cela peut signifier :

\n
• Application desktop : ouvrir une fenêtre, cliquer sur le bouton « Envoyer », vérifier que les données sont bien transmises à la base de données.
\n
• Application serveur : envoyer une requête HTTP à votre API REST, vérifier la réponse et l'état de la base de données.
\n
• Logiciel embarqué : envoyer un signal en entrée, vérifier le signal de sortie après un certain temps.
\n

La différence clé est l'environnement réel. Pas d'objets mock pour la base de données ou le réseau. Uniquement du matériel réel (ou Docker).

Boîte à outils : qu'est-ce qui fonctionne vraiment pour le C++ en 2024 ?

Allons droit au but. Voici la stack que nous utilisons en production :

\n
• Catch2 ou Google Test — pour écrire la structure des tests (Arrange-Act-Assert).
\n
• Docker — pour créer un environnement propre (base de données, files d'attente, dépendances).
\n
• Pytest + subprocess — pour l'orchestration (oui, Python, mais il est idéal pour assembler les binaires C++).
\n
• Selenium/Appium — si vous avez une interface graphique avec Qt ou WebView.
\n
• CMake + CTest — pour lancer les tests et collecter les résultats.
\n

N'essayez pas d'écrire des tests E2E uniquement en C++. C'est douloureux. Utilisez Python comme colle — il est plus rapide pour les scénarios d'intégration.

Pratique : écrivons un test E2E pour une API REST en C++

Supposons que nous ayons un serveur C++ utilisant cpp-httplib (ou crow, ou drogon). Il accepte les requêtes POST à l'adresse /api/user et enregistre l'utilisateur dans PostgreSQL.

Écrivons un test E2E qui :

\n
1. Lance un conteneur Docker avec PostgreSQL.
\n
2. Compile et lance notre serveur.
\n
3. Envoie une requête HTTP via curl (ou un client C++).
\n
4. Vérifie que l'utilisateur est bien apparu dans la base de données.
\n

Étape 1 : Docker-compose pour l'environnement de test

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

Étape 2 : Test en C++ avec 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: Créer un utilisateur via l'API et vérifier dans la base de données") {\n    // Arrange\n    httplib::Client cli("localhost", 8080);\n    nlohmann::json user = {\n        {"name", "John Doe"}