Couverture de code C++ : de Gcov aux métriques qualité

Introduction : Pourquoi des tests "verts" ne signifient pas encore la victoire ?

Imaginez : vous lancez un millier de tests unitaires, tous passent avec un coche vert, le pipeline CI est heureux, le manager est satisfait. Mais une semaine passe, et un bug critique tombe en production. Une situation familière ? Le plus souvent, le problème est que les tests existent, mais ils ne vérifient pas le code réellement exécuté. Ils peuvent ne tester que 10% des sources, tandis que les 90% restants sont une "zone grise" où se cachent les erreurs.

C'est ici qu'entre en scène la couverture de code C++ (code coverage). Ce n'est pas simplement une métrique à la mode pour faire un rapport au client. C'est votre appareil à rayons X qui montre : quelles lignes de code sont réellement exécutées pendant les tests, et lesquelles n'ont jamais été lancées. Aujourd'hui, nous allons voir comment configurer correctement les outils de couverture en C++, quelles métriques sont vraiment importantes, et comment ne pas se noyer dans les faux positifs.

Qu'est-ce que la couverture de code et pourquoi est-elle nécessaire au développeur C++ ?

La couverture de code (code coverage) est une métrique qui indique le pourcentage du code source de votre programme qui a été exécuté lors de l'exécution des tests. En C++, c'est particulièrement critique car le langage permet d'écrire du code bas niveau, des optimisations et de la magie template qui peut "frapper" au moment le plus inattendu.

Les principaux types de métriques de couverture

Toutes les métriques ne se valent pas. Voici ce qui compte vraiment :

\n
• Line Coverage (couverture de lignes) — la métrique la plus basique. Combien de lignes de la source ont été touchées. Facile à mesurer, mais facile à tromper.
\n
• Branch Coverage (couverture de branches) — vérifie si les deux branches de chaque if/else ou switch ont été parcourues. Beaucoup plus honnête que le line coverage.
\n
• Function Coverage (couverture de fonctions) — la fonction a-t-elle été appelée au moins une fois. Utile pour trouver du code "mort".
\n
• Condition Coverage (couverture de conditions) — vérifie toutes les sous-expressions dans les opérateurs logiques complexes (&&, ||). Le plus strict, mais aussi le plus gourmand en ressources.
\n

Pour un projet C++ standard, il est de bon ton de viser un objectif de 70-80% de line coverage et au moins 60% de branch coverage. 100% de couverture est une utopie, mais viser 90% dans les modules critiques (gestion de la mémoire, protocoles réseau) est tout à fait réalisable.

Outils d'analyse de couverture de code C++

L'écosystème C++ propose plusieurs outils puissants. Nous allons voir le top 3, ceux réellement utilisés en production.

1. Gcov — le classique de GCC

gcov est un outil intégré au compilateur GCC. Il fonctionne au niveau du code machine, ce qui donne des résultats très précis. Principaux avantages : gratuit, open source, fonctionne avec CMake et Makefile.

Comment lancer :

// Compilation avec les flags de couverture\ng++ -fprofile-arcs -ftest-coverage -O0 main.cpp -o test_app\n\n// Exécution des tests\n./test_app\n\n// Génération du rapport\ngcov main.cpp

Après cela, vous obtiendrez des fichiers *.gcov qui montrent combien de fois chaque ligne a été exécutée. Inconvénient : le format de sortie est textuel, peu visuel.

2. LCOV — interface graphique pour Gcov

lcov est une surcouche de gcov qui génère de beaux rapports HTML. Vous pourrez voir les lignes vertes (couvertes) et rouges (non couvertes) directement dans le navigateur.

# Collecte des données de couverture\nlcov --capture --directory . --output-file coverage.info\n\n# Génération du HTML\ngenhtml coverage.info --output-directory coverage_report

C'est la référence de l'industrie pour l'IC/DC. Jenkins, GitLab CI, GitHub Actions — partout, vous pouvez configurer la génération automatique de LCOV.

3. Clang Sanitizer Coverage (basé sur les sources)

Si vous utilisez Clang, vous avez accès à -fsanitize-coverage. Ce