Comment implémenter des tests unitaires dans des projets C++ à grande échelle?

Question

Je crois fermement en utilisant des tests unitaires dans le cadre de la construction de grandes applications multiplateformes. Nous planifions actuellement d'effectuer nos tests unitaires dans le cadre d'un projet distinct. Cela a l'avantage de garder notre base de code propre. Je pense, cependant, que cela séparerait le code de test de la mise en œuvre de l'unité. Que pensez-vous de cette approche et existe-t-il des outils comme JUnit pour les applications C++?

Answer 1

Il y a beaucoup de frameforks de l'unité de test pour C++. CppUnit n'est certainement pas celui que je choisirais (au moins dans sa version stable 1.x, car il manque de nombreux tests, et nécessite beaucoup de lignes de codes redondantes). Jusqu'à présent, mon cadre préféré est CxxTest, et je prévois d'évaluer Fructose un jour.

De toute façon, il y a quelques "papiers" qui évaluent les cadres C++ TU:

• Exploring the C++ Unit Testing Framework Jungle, Noel Llopis
• an article in Overload Journal #78

Answer 2

C'est une approche raisonnable.

J'ai eu de très bons résultats à la fois avec UnitTest++ et Boost.Test

Je l'ai regardé CppUnit, mais pour moi, il se sentait plus comme une traduction de la substance JUnit que quelque chose visant à C++.

Mise à jour: Ces jours je préfère utiliser Catch. Je l'ai trouvé efficace et simple à utiliser.

Answer 3

CppUnit est un équivalent direct de Junit C applications de http://cppunit.sourceforge.net/cppunit-wiki

part, je créé les tests unitaires dans un autre projet, et créé une configuration de construction séparée qui construit l'ensemble des tests unitaires et le code source dépendante. Dans certains cas, je voulais tester les fonctions membres privées d'une classe, j'ai donc fait de la classe Test une classe d'amis pour l'objet à tester, mais j'ai caché les déclarations d'amis lors de la construction de configurations "non test" à travers les déclarations du préprocesseur. J'ai fini par faire ces exercices de codage alors que j'intégrais les tests dans le code existant. Si vous commencez avec des tests unitaires, une meilleure conception peut être simple.

Answer 4

Vous pouvez créer un projet de test unitaire pour chaque bibliothèque de votre arborescence source dans un sous-répertoire de cette bibliothèque. Vous vous retrouvez avec une application de pilote de test pour chaque bibliothèque, ce qui facilite l'exécution d'une seule suite de tests. En les mettant dans un sous-répertoire, il maintient votre base de code propre, mais maintient également les tests proches du code.

Il est facile d'écrire des scripts pour exécuter toutes les suites de tests dans votre arborescence source et collecter les résultats.

J'ai utilisé une version personnalisée de l'original CppUnit pendant des années avec beaucoup de succès, mais il existe d'autres alternatives maintenant. GoogleTest semble intéressant.

Answer 5

Je pense que vous êtes sur la bonne voie avec des tests unitaires et c'est un excellent plan pour améliorer la fiabilité de votre produit.

Bien que les tests unitaires ne résolvent pas tous vos problèmes lors de la conversion de votre application sur différentes plates-formes ou même sur différents systèmes d'exploitation. La raison en est que les tests de l'unité de traitement permettent de découvrir des bogues dans votre application. Il jette tout simplement autant d'entrées imaginables dans votre système et attend un résultat à l'autre extrémité. C'est comme si un singe frappait constamment au clavier et observait les résultats (bêta-testeurs).

Pour passer à l'étape suivante, avec de bons tests unitaires, vous devez vous concentrer sur la conception interne de votre application. La meilleure approche que j'ai trouvée consistait à utiliser un modèle de conception ou un processus de conception appelé «programmation par contrat» ou «conception par contrat». L'autre livre qui est très utile pour construire la fiabilité dans votre conception de base était.

Débogage du processus de développement: stratégies pratiques pour rester concentré, atteindre les dates de livraison et constituer des équipes solides.Dans notre équipe de développement, nous avons examiné de très près ce que nous considérons comme une erreur de programmeur, une erreur de développeur, une erreur de conception et comment nous pourrions utiliser à la fois les tests unitaires et la fiabilité de construction de notre logiciel via DBC. de déboguer le processus de développement.

Answer 6

CxxTest vaut également le coup d'œil pour une structure légère, facile à utiliser, multi-plateforme JUnit/CppUnit/xUnit pour C++. Nous trouvons très simple d'ajouter et de développer des tests

Aeryn est un autre cadre de test C++ intéressant de regarder

Answer 7

J'utilise UnitTest ++. Les tests sont dans un projet distinct, mais les tests réels sont étroitement liés au code réel. Ils existent dans un dossier sous la section en cours de test. -à-dire:
MyProject \ src \ < - source de l'application réelle
MyProject \ src \ Tests < - la source des essais
Si vous avez des dossiers imbriqués (et qui ne font pas) alors eux aussi auront leur Propre sous-répertoire \ tests.

Answer 8

En utilisant tut http://tut-framework.sourceforge.net/ très simple, juste fichier d'en-tête seulement pas de macros. Peut générer des résultats XML

Answer 9

Vous devez séparer votre code de base en une bibliothèque partagée (dynamique), puis écrire la majeure partie de vos tests unitaires pour cette bibliothèque.

Il y a deux ans (2008), j'ai participé à un important projet d'infrastructure LSB déployé par la Linux Foundation. L'un des objectifs de ce projet était d'écrire des tests unitaires pour 40.000 fonctions à partir des bibliothèques centrales de Linux. Dans le cadre de ce projet, nous avons créé le AZOV technology et l'outil de base nommé API Sanity Autotest afin de générer automatiquement tous les tests. Vous pouvez essayer d'utiliser cet outil pour générer des tests unitaires pour votre bibliothèque (s) de base.