Tests en C++ (compétence « Agent »)

Workflow de tests axé sur les agents pour le C++ moderne (C++17/20) utilisant GoogleTest/GoogleMock avec CMake/CTest.

Quand l'utiliser

• Rédaction de nouveaux tests C++ ou correction de tests existants
• Concevoir une couverture de tests unitaires/d’intégration pour des composants C++
• Ajouter une couverture de test, des contrôles d'intégration continue (CI) ou une protection contre les régressions
• Configuration de workflows CMake/CTest pour une exécution cohérente
• Analyser les échecs de test ou les comportements instables
• Activer les « sanitizers » pour le diagnostic des problèmes de mémoire et des conflits d'accès

Quand NE PAS l’utiliser

• Mise en œuvre de nouvelles fonctionnalités du produit sans modification des tests
• Refactorisations à grande échelle sans rapport avec la couverture de test ou les échecs
• Optimisation des performances sans régressions de tests pour la validation
• Projets non-C++ ou tâches non liées aux tests

Concepts fondamentaux

• Boucle TDD : rouge → vert → refactorisation (tests d’abord, correction minimale, puis nettoyages).
• Isolation : privilégier l’injection de dépendances et les simulacres plutôt que l’état global.
• Structure des tests : tests/unit, tests/integration, tests/testdata.
• Mocks vs fakes : les mocks pour les interactions, les fakes pour les comportements avec état.
• Découverte des tests : utilisez gtest_discover_tests() pour une découverte stable des tests.
• Signal CI : exécutez d'abord un sous-ensemble, puis la suite complète avec --output-on-failure.

Workflow TDD

Suivez la boucle ROUGE → VERT → REFACTORISATION :

1. ROUGE : écrivez un test qui échoue et qui capture le nouveau comportement
2. VERT : implémentez la modification minimale nécessaire pour que le test réussisse
3. REFACTOR : nettoyez le code tant que les tests restent verts

// 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

Exemples de code

Test unitaire de base (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");
}

Simulation (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");
}

Guide de démarrage rapide CMake/CTest

# 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

Exécution des tests

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

Débogage des échecs

1. Relancez le test ayant échoué à l'aide du filtre gtest.
2. Ajoutez une journalisation localisée autour de l'assertion qui échoue.
3. Relancez le test avec les « sanitizers » activés.
4. Étendre la suite de tests à l'ensemble des tests une fois la cause première corrigée.

Couverture

Privilégiez les paramètres au niveau de la cible plutôt que les indicateurs globaux.

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

Sanitiseurs

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

Tests instables Mesures de sécurité

• N'utilisez jamais sleep pour la synchronisation ; utilisez plutôt des variables de condition ou des latches.
• Créez des répertoires temporaires uniques pour chaque test et videz-les systématiquement.
• Évitez les dépendances en temps réel, réseau ou système de fichiers dans les tests unitaires.
• Utilisez des graines déterministes pour les entrées aléatoires.

Bonnes pratiques

À FAIRE

• Veillez à ce que les tests soient déterministes et isolés
• Privilégiez l'injection de dépendances plutôt que les variables globales
• Utilisez ASSERT_* pour les préconditions, EXPECT_* pour les vérifications multiples
• Séparer les tests unitaires des tests d'intégration dans les étiquettes ou les répertoires CTest
• Exécutez des outils de nettoyage en CI pour la détection des problèmes de mémoire et des conflits d'accès

À NE PAS FAIRE

• Ne pas dépendre du temps réel ou du réseau dans les tests unitaires
• N’utilisez pas de commandes « sleep » comme mécanisme de synchronisation lorsqu’une variable de condition peut être utilisée
• Ne simulez pas excessivement les objets de valeur simples
• N’utilisez pas de comparaisons de chaînes de caractères instables pour les journaux non critiques

Pièges courants

• Utilisation de chemins d'accès temporaires fixes → Générez des répertoires temporaires uniques pour chaque test et nettoyez-les.
• S'appuyer sur l'heure réelle → Injecter une horloge ou utiliser de fausses sources de temps.
• Tests de concurrence instables → Utilisez des variables de condition/verrous et des attentes bornées.
• État global caché → Réinitialisez l'état global dans les fixtures ou supprimez les variables globales.
• Mocking excessif → Privilégier les fakes pour les comportements avec état et ne simuler que les interactions.
• Exécutions de sanitizer manquantes → Ajouter des builds ASan/UBSan/TSan dans l'intégration continue (CI).
• Couverture sur les builds « debug-only » → S’assurer que les cibles de couverture utilisent des indicateurs cohérents.

Annexe facultative : Fuzzing / Tests de propriétés

À n'utiliser que si le projet prend déjà en charge LLVM/libFuzzer ou une bibliothèque de tests de propriétés.

• libFuzzer : idéal pour les fonctions pures avec un minimum d'E/S.
• RapidCheck : tests basés sur les propriétés pour valider les invariants.

Harnais libFuzzer minimal (pseudo-code : remplacer ParseConfig) :

#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;
}

Alternatives à GoogleTest

• Catch2 : uniquement en en-tête, matchers expressifs
• doctest : léger, surcoût de compilation minimal