Version imprimable
Bonjour,
J'aimerais avoir vos avis concernant les différentes solutions de tests unitaires en c++.
Parmi celles que vous avez déjà utilisées,
:arrow: quelles sont celles qui sont les plus faciles à installer, configurer (automatisation), utiliser et maintenir ?
:arrow: sur quel(s) système(s) d'exploitation fonctionnent-elles ?
:arrow: sont-elles gratuites ?
:arrow: sont-elles dépendantes d'un IDE donné ?
:arrow: sont-elles fiables ?
Salut !
Je n'en ai pas testé beaucoup mais j'aime bien GTest, pour les raisons suivantes:
- Facilité d'usage.
- Facilité de mise en place : simple et peu de dépendances, facile à intégrer dans un projet.
- Facilité pour rejouer un test ou set de tests donné (ça parait trivial et pourtant ce que ça peut être chiant avec certains !)
- Customisation aisée des formats de sorties avec les "listeners" qui permettent de générer des rapports sous différentes formes.
Inconvénient remarqué: de base, GTest s'utilise en ne compilant qu'un seul exécutable qui fait tout. Du coup, un segfault peut te pourrir un replay de nuit par exemple car plus aucun test ne sera joué après.
Concernant tes points:
- Intégration: GTest ne fait rien à part te donner les clés pour générer des rapports sous le format qui te convient. Dans mon cas je générais des TAP pour Jenkins, c'est fait en 10 lignes de code c'est bidon.
- Plateforme: A priori Windows/Mac/Linux. Testé sous linux
- Licence: New BSD
- Dépendance à un IDE: niet, s'intègre très bien dans Eclipse CDT.
- Fiabilité : Difficile à mesurer, aucun problème à déplorer pour ma part.
Je vais suivre de près aussi, ça m'intéresse ! ;)
J'ai jamais utilisé, mais on m'a très fortement conseillé cppUnit
http://matthieu-brucher.developpez.c...s/cpp/cppUnit/
J'utilisais CPPUnit lors de ma précédente mission : je sais pas pour la mise en place, mais à l'utilisation c'est fort simple !
J'ai utilisé cppunit et boost.test, et un tout petit peu la bibliothèque livrée dans visual studio 2012.
Je trouve cppUnit inutilement lourd, à la mise en place comme à l'utilisation (besoin d'enregistrer manuellement les cas de test, besoin de comparer des valeurs de même type, et pas simplement de types compatibles (par moyen de faire un test entre une std::string et un litéral de type char const *...)).
J'avais préféré boost::test (mieux packagé, rien à faire pour la mise en place, tests auto enregistrée, bonne instrumentation du code (fuites mémoires, désactivation des asserts...)).
J'ai un souvenir de CppUnit v1 inutilement complexe à utiliser (p.ex. tests à recenser 2 fois), avec avec beaucoup de manque dans les trucs testables. Pour moi il ne doit sa bonne réputation qu'à son nom pour ceux qui viennent de jUnit. Pour un public qui connait le C++, il y a mieux (la profusion de frameworks de TU en C++ est d'ailleurs pour moi un indice que CppUnit est un échec alors que jUnit me semble dominer l'écosystème Java)
A l'époque j'utilisais CxxTest (.sf.net) qui reposait sur un script Perl et qui avait un vocabulaire bien plus riche. Le seul défaut était lié à l'affichage de données utilisateur pas toujours simple à mettre en oeuvre. Depuis le script a été réécrit en python et je n'ai plus eu l'occasion de l'essayer.
Depuis donc j'ai essayé boost.test. Il n'est pas inutilement lourd, il fait son job, son vocabulaire est suffisamment riche. Le format des erreurs est bon (i.e. même format que celui de tous les outils *nix). S'il fallait lui trouver un défaut : le besoin de disposer du .so pour pouvoir s'en servir.
Je n'ai pas essayé google.test, il m'a l'air comparable.
Pour info j'utilise CTest pour encapsuler la gestion de tous les tests. Plein d'avantages relativement à CDash, relativement à la possibilité de tester des résultats produits (stdout/fichier(s)) (bien que la macro pour faire ça est àécrirebidouiller soi même, et que c'est très très mal documenté).
Un défaut pour moi toutefois: les lignes sont préfixées par les numéros des tests (/des threads dans le cas de la compilation), j'ai dû rajouter un hack dans ma conf vim pour pouvoir nettoyer ce parasitage.
Hello,
Pour ma part c'est coup de coeur pour gtest. (1.6)
Les macros sont claires, assert, expect, cest facile d'executer un test simples, ecrire un test est simple.
Cppunit, pour moi cest trop complique. Creer des classes de tests, des sources etc... brr.
Ctest jai teste aussi, de memoire cest appeler lexecutable plein de fois avec differents parametres, je trouve ca bof. Mais cest vrai qu'associe au reporting CDash, c'est sympa.
Par contre, il est possible de se servir de gtest avec une bonne vieille macro (CMakeLists) couplee a CTest (pour pouvoir beneficier de la facilite decriture de tests avec gtest+reporting propose par CDash)
En effet gtest à l'air vraiment bien. De plus, j'ai vu qu'il existe déjà quelques logiciels à priori sérieux, se basant sur gtest, qui proposent des améliorations intéressantes.
Mais boost a 2 avantages qui me paraissent non négligeables: boost est souvent intégré au cycle de développement (donc ça ne rajoute pas de dépendance supplémentaire), et boost inspire plus confiance (nous l'utilisons depuis longtemps).
Quels paramètres supplémentaires pour CTest ?
Ton TU soit tu l'appelles directement si ça te fais plaisir, soir tu l'appelles via CTest (soit juste lui, soit tous les TU, soit certains TU (identifiés par numéro ou regex sur le nom), au besoin).
Après il y a des paramètres bien cachées qui permettent de lancer l'exécution des TUs tout en calculant des taux de couverture du code, ou via valgrind.
Si t'as déjà fait ça, ça m'intéresse.Citation:
Envoyé par galerien69
ici un exemple:
ce qui consiste à appeler lexecutable avec en paramètre le nombre du test parsé par cette macro et ce pour chaque test.Code:
2
3
4
5
6
7
8
9
10
11
Du coup, ya pas besoin de "référencer" la liste des tests dans le CMakeLists, c'est fait par la macro qui parse les fichiers!
J'ai plus les sources, mais je peux reconstruire un ex si nécessaire, c'est assez immédiat
Ca ira je pourrais me débrouiller avec tes références, merci pour l'astuce !
Bonjour à tous,
Je suis complètement novice dans les tests unitaires, et d'un point de vue de débutant, je peux vous dire que CppUnit n'est pas facile à mettre en place.
Je ne peux pas comparer avec beaucoup d'outils, mais j'utilise actuellement UnitTest++ qui est beaucoup plus facile à mettre en place, et est apparemment reconnu pour être léger d'utilisation.
Bonjour,
sur tous mes projets, pro et perso, j'utilise un fork maison de cpp unit lite, très simple à utiliser.
Bonjour,
Personnellement, avant j'utilisais WinUnit (http://winunit.codeplex.com/) puisque c'était le résultat qui sortait le plus souvent dans mes recherches google.
Depuis que j'ai vu ce topic, je me lance dans l'utilisation de GTest. :)
Yet Another Framework for Unit-Testing : http://members.home.nl/rutger.van.beusekom/
Très simple à mettre en place et à utiliser .....
A voté : Aucune, je ne fais pas de tests unitaires.
je conseil Boost.test, dans ma boite on a testé google test cppunit et on a adopté boost.test. Sous visual en créer un petit plugin il est possible de ne lancer qu'un seul test au lieu de tous, très pratique .
Dommage d'aller jusqu'à la création d'un plugin pour ça :mrgreen: Dans boost.test je ne sais pas mais dans gtest c'est une option à passer sur l'exécutable généré (et ça prend des patterns et tout, c'est pas mal).Citation:
Envoyé par guillaume07