GoogleTest : le framework de test C++ de Google, passé à C++17

Un framework né d'une fusion

GoogleTest se présente comme le framework de test et de simulation de Google pour C++. Le dépôt est le résultat d'une fusion : les projets GoogleTest et GoogleMock, jadis séparés, sont aujourd'hui maintenus et publiés ensemble, tant leurs sujets se recouvrent. Le projet affiche 39 147 étoiles, 10 869 forks et 493 issues ouvertes. La documentation recommandée ne vit plus dans le dépôt : elle est publiée sur GitHub Pages, google.github.io/googletest, avec le GoogleTest Primer comme point de départ annoncé. L'intégration continue n'est pas publique non plus : le README indique que Google utilise ses systèmes internes pour la CI, un point à connaître quand on évalue la transparence du projet.

La 1.18.0 impose C++17 et prépare Abseil

La section Annonces du README concentre l'actualité. La release 1.18.0 est disponible, et la branche 1.18.x exige au minimum C++17, en référence à la politique de support C++ fondamentale de Google. Autre signal : une dépendance à Abseil est annoncée comme prochaine étape, ce qui modifiera la manière d'intégrer la bibliothèque dans les projets. Le calendrier des releases montre un rythme annuel environ : v1.16.0 en février 2025, v1.17.0 en avril 2025, v1.18.0 en août 2026. Pour un projet C++ resté sur une norme antérieure, l'effet est concret : rester sur une branche antérieure ou monter la norme du compilateur, l'arbitrage devant être fait explicitement.

De la découverte des tests aux death tests

La liste des fonctionnalités couvre l'essentiel attendu d'un framework xUnit. La découverte automatique des tests supprime l'enregistrement manuel. Les assertions fournies couvrent égalité, inégalité, exceptions et plus, avec possibilité d'en définir soi-même. Les death tests vérifient que le code se termine d'une certaine manière, utile pour le traitement d'erreurs. Les échecs peuvent être fatals ou non fatals, laissant la suite s'exécuter après un échec. Les tests paramétrés par valeur rejouent un test sur plusieurs entrées, ceux paramétrés par type sur plusieurs types de données. Enfin, l'exécution offre des options : tests individuels, ordre spécifique, parallélisme. Cet ensemble explique la longévité du framework dans les projets C++ établis.

Construire avec CMake : autonome ou FetchContent

Le README de build documente deux intégrations CMake. En autonome : cloner le dépôt, créer un répertoire build, lancer cmake, puis make, avec sudo make install vers /usr/local par défaut sur les systèmes de type Unix ; la désactivation de GoogleMock se fait par -DBUILD_GMOCK=OFF. Dans un projet existant, deux approches coexistent : find_package(GTest CONFIG REQUIRED) avec les cibles GTest::gtest et GTest::gmock, ou l'intégration décrite comme plus robuste et flexible via add_subdirectory ou FetchContent, qui exige CMake 3.14 ou plus. L'exemple du README épingle une URL pointant vers un commit précis, une pratique à suivre pour des builds reproductibles plutôt qu'un suivi de branche.

Threads, bibliothèque partagée et macros renommables

Trois réglages fins sont documentés. La sûreté des threads : GoogleTest est thread-safe là où pthread est disponible, la macro GTEST_IS_THREADSAFE valant 1 après inclusion de gtest/gtest.h, avec forçage possible par -DGTEST_HAS_PTHREAD=1 ou 0. La bibliothèque partagée : construire avec -DGTEST_CREATE_SHARED_LIBRARY=1 et compiler les tests liés avec -DGTEST_LINKED_AS_SHARED_LIBRARY=1, le README signalant que ces drapeaux pourraient devenir obligatoires. Les conflits de macros enfin : puisque les macros C++ ignorent les espaces de noms, -DGTEST_DONT_DEFINE_FOO=1 désactive la macro FOO, TEST devenant alors GTEST_TEST. La liste complète des macros de configuration vit dans include/gtest/internal/gtest-port.h.

Chromium, LLVM, protobuf et OpenCV l'utilisent

Le README appuie sa crédibilité sur une liste d'utilisateurs nommés : les projets Chromium, derrière Chrome et Chrome OS, le compilateur LLVM, Protocol Buffers, le format d'échange de données de Google, et la bibliothèque de vision par ordinateur OpenCV, en plus des projets internes de Google. Les plateformes suivent la politique de support C++ fondamentale de Google, avec une table publique des versions de compilateurs, plateformes et outils de build pris en charge. Pour une équipe qui choisit un framework de test, cette assise réduit le risque de dépendance : le framework est exercé à très grande échelle, et ses évolutions, comme l'exigence C++17, sont documentées par une politique écrite plutôt qu'au cas par cas.

Runners tiers et licence BSD-3-Clause

Un écosystème d'outils gravite autour du framework, listé dans le README : GTest Runner, une interface graphique Qt5 pour Windows et Linux, GoogleTest UI écrit en C#, GTest TAP Listener qui sort les résultats au protocole TAP, gtest-parallel pour l'exécution parallèle, les extensions VS Code GoogleTest Adapter et C++ TestMate, et Cornichon, un parseur Gherkin qui génère des stubs pour GoogleTest. La licence est BSD-3-Clause : usage, modification et redistribution libres, y compris commerciaux, avec conservation de la notice et sans garantie. Les contributions suivent CONTRIBUTING.md. Le README se ferme sur un happy testing qui résume l'esprit d'un project volontairement sobre en cérémonie.

Conclusion éditoriale

GoogleTest s'impose comme choix par défaut pour tester du C++ lorsqu'aucune contrainte de norme ancienne ne s'y oppose : la branche 1.18.x exige au minimum C++17, et une dépendance à Abseil est annoncée. L'intégration CMake la plus robuste documentée passe par FetchContent avec CMake 3.14 ou plus, en épinglant un commit précis ; les projets restés en C++ antérieur doivent rester sur une branche 1.17.x ou antérieure. Avant migration, vérifiez la matrice de support des compilateurs liée au README et relisez la liste des fonctionnalités pour confirmer que vos usages, death tests et tests paramétrés, restent couverts.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes