TDD en C++ : Développement piloté par les tests pour les génies paresseux

Introduction : pourquoi écrivons-nous des bugs, puis les corrigeons-nous héroïquement ?

Avez-vous déjà écrit du code qui fonctionnait "à peu près normalement", puis, trois jours plus tard, trouvé un bug qui faisait tout s'effondrer ? Si oui — bienvenue au club. Si non — vous êtes soit un dieu du C++, soit vous n'avez tout simplement pas encore mis en production.

Le développement piloté par les tests (TDD) n'est pas un régime à la mode pour les programmeurs. C'est une discipline qui bouleverse le processus d'écriture du code. Au lieu d'écrire d'abord la logique, puis de chercher frénétiquement comment la tester, nous faisons l'inverse : d'abord le test, puis le code. Cela semble fou ? Peut-être. Mais c'est ainsi que naît un code dont on n'a pas honte de montrer à ses collègues et qui ne casse pas le vendredi soir.

Dans cet article, nous allons décortiquer le TDD en C++ avec des exemples concrets : nous écrirons une bibliothèque simple pour travailler avec les nombres de Fibonacci, en utilisant le cycle Red-Green-Refactor. Vous verrez comment le TDD aide non seulement à éviter les bugs, mais aussi à concevoir des interfaces.

Qu'est-ce que le TDD et pourquoi le C++ sans lui est comme une voiture sans freins ?

TDD (Test-Driven Development) est une méthodologie de développement où l'on écrit d'abord un test qui échoue volontairement (Red), puis on écrit le code minimal pour faire passer le test (Green), et enfin on refactore (Refactor) pour améliorer la structure sans changer le comportement.

Pourquoi est-ce important spécifiquement pour le C++ ? Parce que le C++ est un langage où il est facile de se tirer une balle dans le pied : comportement indéfini, fuites mémoire, conversions de types incorrectes. Le TDD crée automatiquement un filet de sécurité qui attrape les erreurs à la compilation et à l'exécution.

Le cycle Red-Green-Refactor : comment ça marche

\n
• Red : on écrit un test qui doit échouer. C'est notre "exigence" pour le code.
\n
• Green : on écrit le code minimal pour que le test réussisse. Pas de sur-ingénierie !
\n
• Refactor : on améliore le code (on supprime les doublons, on simplifie la logique) — les tests restent verts.
\n

Cela semble simple ? Oui. Mais en pratique, cela demande de la discipline. Essayons.

Outils pour le TDD en C++ : Google Test vs Catch2

Avant d'écrire du code, choisissons un framework de test. Deux candidats principaux :

\n
• Google Test — puissant, populaire, avec une multitude de macros. Idéal pour les grands projets.
\n
• Catch2 — léger, moderne, avec une syntaxe pratique. Parfait pour les exemples pédagogiques et les microservices.
\n

Dans cet article, nous utiliserons Catch2 (v3), car il est minimaliste et ne nécessite pas de configuration superflue. Mais si vous préférez Google Test — les principes du TDD sont les mêmes.

Pratique : écrivons du TDD pour les nombres de Fibonacci

Imaginons que nous devions écrire une fonction fibonacci(int n) qui retourne le n-ième nombre de Fibonacci (0e = 0, 1er = 1, 2e = 1, 3e = 2, etc.).

Étape 1 : Red — écrivons un test qui échoue

Créons un fichier test_fib.cpp :

#define CATCH_CONFIG_MAIN\n#include <catch2/catch_test_macros.hpp>\n\n// La fonction n'est pas encore déclarée — c'est normal\nint fibonacci(int n);\n\nTEST_CASE("Nombres de Fibonacci", "[fib]") {\n    REQUIRE(fibonacci(0) == 0);\n    REQUIRE(fibonacci(1) == 1);\n    REQUIRE(fibonacci(2) == 1);\n    REQUIRE(fibonacci(10) == 55);\n}

On essaie de compiler — on obtient une erreur de linkage. Le test est RED. Parfait !

Étape 2 : Green — écrivons le code minimal pour que le test réussisse

Créons un fichier fib.cpp :

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

On compile et on exécute les tests. Ils réussissent ? Oui, mais ce n'est pas efficace. Cependant, notre objectif est Green, pas la perfection. On laisse comme ça pour l'instant.

Étape 3 : Refactor —