Framework de test unitaire C ++

J’utilise le framework Boost Test pour mon code C ++, mais il y a deux problèmes qui sont probablement communs à tous les frameworks de test C ++:

  • Il est impossible de créer des stubs de test automatiques (en extrayant des fonctions publiques de classes sélectionnées par exemple).
  • Vous ne pouvez pas exécuter un seul test – vous devez exécuter l’intégralité de la suite de tests (sauf si vous créez de nombreux projets de test différents, je suppose).

Est-ce que quelqu’un connaît un meilleur cadre de test ou suis-je toujours jaloux des outils de test disponibles pour les développeurs Java / .NET?

Je viens de répondre à une question très similaire . J’ai fini par utiliser UnitTest ++ de Noel Llopis. Je l’ai aimé plus que boost :: test car il n’a pas insisté sur l’implémentation du programme principal du harnais de test avec une macro – il peut se connecter à n’importe quel exécutable que vous créez. Il souffre du même encombrement de boost :: test car il nécessite une bibliothèque pour être lié. J’ai utilisé CxxTest, et il se rapproche plus que toute autre chose en C ++ – il génère automatiquement des tests (bien qu’il nécessite Perl faire partie de votre système de construction pour ce faire). C ++ ne fournit tout simplement pas les crochets de reflection utilisés par les langages .NET et Java. Les outils MsTest de Visual Studio Team System – Developer’s Edition génèrent automatiquement des stubs de test de C ++ non gérés, mais les méthodes doivent être exscopes à partir d’une DLL afin de ne pas fonctionner avec des bibliothèques statiques. D’autres frameworks de test dans le monde .NET peuvent également avoir cette capacité, mais je ne connais aucun de ceux-ci. Donc, en ce moment, nous utilisons UnitTest ++ pour le C ++ non géré et je décide actuellement entre MsTest et NUnit pour les bibliothèques gérées.

Je viens de repousser mon propre cadre, CATCH . Il est encore en développement mais je pense qu’il dépasse déjà la plupart des autres frameworks. Différentes personnes ont des critères différents, mais j’ai essayé de couvrir la plupart des problèmes sans trop de compromis. Jetez un oeil à mon entrée de blog liée pour un dégustateur. Mes cinq principales caractéristiques sont les suivantes:

  • En-tête seulement
  • Enregistrement automatique des tests basés sur les fonctions et les méthodes
  • Décompose les expressions C ++ standard dans LHS et RHS (vous n’avez donc pas besoin de toute une famille de macros d’assertion).
  • Prise en charge des sections nestedes dans un appareil basé sur une fonction
  • Tests de nom utilisant le langage naturel – les noms de fonction / méthode sont générés

Il ne fait pas de génération de souches – mais c’est un domaine assez spécialisé. Je pense qu’Isolator ++ est le premier outil pour vraiment réussir. Notez que les frameworks Mocking / Stubbing sont généralement indépendants des frameworks de tests unitaires. CATCH fonctionne particulièrement bien avec des objects fictifs car l’état de test n’est pas transmis par contexte.

Il possède également des liaisons Objective-C.

[mettre à jour]

Je viens juste de revenir sur cette réponse de moi il y a quelques années. Merci pour tous les super commentaires! De toute évidence, Catch a beaucoup évolué à cette époque. Il prend désormais en charge les tests de style BDD (donnés / quand / alors), les balises, désormais dans un seul en- tête, et les nombreuses améliorations et améliorations internes (ligne de commande plus riche, résultats clairs et expressifs, etc.). Un article de blog plus récent est ici.

Jetez un coup d’œil au framework de test Google C ++.

Il est utilisé par Google pour tous leurs projets C ++ internes, donc il doit être très bon.

http://googletesting.blogspot.com/2008/07/announcing-new-google-c-testing.html

http://code.google.com/p/googletest

Boost.Test permet d’exécuter un test élémentaire par nom. Ou suite de test. Ou plusieurs d’entre eux.

Boost.Test n’insiste PAS sur la mise en œuvre principale, bien que cela facilite la tâche.

Boost.Test n’est PAS nécessaire d’utiliser comme bibliothèque. Il a une variante d’en-tête unique.

Je suis un grand fan de UnitTest ++ , c’est très léger, mais fait le travail. Vous pouvez y exécuter des tests simples facilement.

Bonne question! Il y a quelques années, j’ai toujours cherché quelque chose qui valait la peine d’être utilisé. Je cherchais quelque chose de très léger et qui ne nécessitait pas de lien dans certaines bibliothèques … vous savez quelque chose que je pourrais utiliser en quelques minutes.

Cependant, j’ai persisté et j’ai fini par courir sur cxxtest .

Depuis le site:

  • Ne nécessite pas de RTTI
  • Ne nécessite pas de fonctions de modèle de membre
  • Ne nécessite pas de gestion des exceptions
  • Ne nécessite aucune bibliothèque externe (y compris la gestion de la mémoire, les E / S de fichier / console, les bibliothèques graphiques)
  • Est dissortingbué entièrement sous la forme d’un ensemble de fichiers d’en-tête (et d’un script python).

Wow … super simple! Incluez un fichier d’en-tête, dérivez de la classe Test et vous êtes hors service. Nous l’utilisons depuis quatre ans et je n’ai toujours pas trouvé quelque chose qui me plaise davantage.

Essayez WinUnit . Cela semble excellent et est recommandé par John Robbins .

J’aime le framework de test d’unité Boost, principalement parce qu’il est très léger.

  • Je n’ai jamais entendu parler d’un framework de test unitaire qui générerait des stubs. Je suis généralement peu convaincu par la génération de code, ne serait-ce que parce que cela devient très vite obsolète. Peut-être cela devient-il utile lorsque vous avez un grand nombre de classes?

  • Un partisan de Test Driven Development dirait probablement qu’il est fondamental que vous exécutiez la suite de tests complète à chaque fois, afin de vous assurer que vous n’avez pas introduit de régression. Si l’exécution de tous les tests prend trop de temps, vos tests sont peut-être trop volumineux ou font-ils trop d’appels vers des fonctions gourmandes en ressources du processeur qui devraient être supprimées? Si cela rest un problème, une enveloppe mince autour des tests unitaires de boost devrait vous permettre de choisir vos tests, et serait probablement plus rapide que d’apprendre un autre framework et de porter tous vos tests.

J’utilise tut-framework

Aeryn est un autre cadre intéressant

Visual Studio a un framework de test unitaire intégré, c’est un excellent lien pour configurer un projet de test pour une application console Win32:

http://codeketchup.blogspot.ie/2012/12/unit-test-for-unmanaged-c-in-visual.html

Si vous travaillez sur un projet DLL statique, il est beaucoup plus facile à configurer, car d’autres ont mis en évidence des structures d’essais externes comme GTest et Boost qui ont des fonctionnalités supplémentaires.

CppUnit était l’hommage original à JUnit.

Eclipse / JUnit est un package solide pour Java, et il existe des extensions / équivalents C ++ pour les deux. Cela peut faire ce dont vous parlez. Bien sûr, il faudrait changer les IDE …

Je suis aussi un fan de UnitTest ++.

Le problème est que la dissortingbution source contient près de 40 fichiers séparés. Ceci est absurde. La gestion du contrôle des sources et des tâches de génération pour un projet simple est dominée par la recherche de tous ces fichiers de tests unitaires.

J’ai modifié UnitTest ++ pour qu’il puisse être intégré à un projet en ajoutant un fichier .h et .cpp. Ce que j’ai surnommé “le plus mignon”. Les détails sont à http://ravenspoint.com/blog/index.php?entry=entry080704-063557

Il ne génère pas automatiquement des stubs de test, comme demandé dans la question d’origine. Je ne peux pas m’empêcher de penser qu’une telle fonctionnalité poserait plus de problèmes qu’elle n’en vaut la peine, générant de grandes quantités de fonctions d’accesseur de “test” inutiles.

J’imagine que supprimer automatiquement les fonctions de test serait plutôt une fonction (des scripts pour le framework ou) de l’environnement de développement en question. Les applications C ++ Builder de CodeGear vont générer rapidement du code de test pour les fonctions utilisateur.

La bibliothèque de fructose d’Andrew Marlow vaut le détour … http://fructose.sourceforge.net/

Je me souviens de ses documents contenant une parsing assez détaillée et une comparaison d’autres offres au moment où il a écrit Fructose, mais je ne trouve pas d’URL directe dans ce document.

J’essaie Igloo , également une suite de tests C ++ uniquement en-tête, même les deux dépendances incluses sont uniquement en-tête.

Donc, c’est assez simple et simple. Outre l’exemple inclus sur github, il y a des exemples et plus de détails sur le site principal, igloo-testing.org . Je le mettrai à jour plus tard, car j’aurai plus d’expérience avec d’autres frameworks.