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
Personnellement je n'utilise pas de tests unitaires mais j'aimerai en mettre en place pour certaines libs de mes programmes. Seulement le temps me manque. On a beau dire que les tests unitaires font gagner du temps, et je le crois aussi, ils ne font pas gagner de temps quand on a deja du code qui marche, et sur-utilise et dont on aimerai ajouter des tests unitaire pou les changements futures qui ne sont pas plannifies.
Donc j'aimerai bien, mais c'est difficile de m'y mettre dans mes projets actuels (si j'etait pas seul dessus ou avec un language moins type que C++ ca serait une autre histoire cela dis).
J'ai un souci pour le choix du framework:
- Boost.Test a l'air d'etre le plus simple a mettre en place, en etant pourtant tres pousse;
- les gens de Boost sont pas tous content de Boost.Test - d'apres les recentes discussions- mais de recentes modifications (je sais pas si elles sont publiees deja) sont cense corriger les problemes;
- Google Test est tres repute et semble tres complet - on me l'a recommande notemment a cause de du framework de mock mais je ne suis pas certain que je vais en avoir besoin...
- Google Test est visiblement plus complique a mettre en place essentiellement parcequ'il genere du code via python, donc il faut python d'installe - compare a Boost.Test qui necessite...C++.
- GTest utilise CMake et j'utilise CMake - Boost.Test est header-only;
- Les deux sont en fait des dependences de dependances d'un de mes projets, donc je peu utiliser l'un ou l'autre (mais dans tous les cas ca va me demander pas mal de travail d'integrer les projets de tests, avant meme d'ecrire les tests);
Du coup je suis reste sur un statut quo de faire en sorte que pas une seule ligne de code ne soit pas utilisee, et que tout est fortement typee. C'est pas l'ideal pour l'evolution de certaines parties, nottemment les plus generiques, mais pour l'instant, comme je disais, j'ai un souci de manque de temps.
Si je pouvais plannifier suffisamment de temps pour integrer un de ces frameworks, ecrire les tests serait du gateau. Malheureusement, mes projets actuels sont assez massifs et utilisent CMake donc ca necessite de l'organisation, du script etc pour facilement ajouter des tests au fur et a mesure.
Et ca commence par decider quel framework utiliser. :aie:
Note: je n'ai pas vote.
Je ne sais pas d'où tu sors ça mais quand je m'en suis servi ce n'était pas du tout le cas :| Juste une lib à linker, pur C++. Ce n'est pas header only en effet. GTest est trivial à mettre en place.Citation:
Envoyé par Klaim
Same here, au boulot. Le code reste bien couvert par des tests d'intégration automatisés, heureusement.Citation:
Envoyé par Klaim
J'essaye GTest, et quand je mets un ASSERT_TRUE, IntellSense râle (pas de problème à la compilation), et ça souligne en rouge.
Quelqu'un a trouvé comment résoudre cet agaçant problème ?
Salut,En fait, je crois qu'il n'est jamais trop tard pour mettre une politique de tests unitaires en place, même si "le plus tôt est surement le mieux".Citation:
Envoyé par Klaim
Il est clair que l'idéal est de le faire avant même d'écrire la première fonction et d'arriver à envisager dés le départ un maximum de cas de figure pour chaque fonction que l'on va écrire, histoire de veiller à passer, dans les fonctions les plus simples, de manière systématique par "tous les chemins possibles" et, si possible, en prenant en compte certaines valeurs qui risquent de poser problème ( du genre d'un 0 comme dénominateur, qui risque de foutre pas mal le b...del :D)
Mais, à défaut de vivre dans un monde idéal, une autre solution est:
Lorsque j'ai commencé ma précédente mission, je suis arrivé sur un projet composé de près de deux mille fichiers (je te laisse imaginer le nombre de fonctions membre que cela peut représenter :D), dont le développement s'étalait déjà sur plusieurs années et pour lequel la politique de tests unitaires se mettait à peine en place.
- De créer un sénario de test qui reproduit un bug lorsque l'on essaye de le corriger (cela peut occasionner l'écriture de plusieurs tests, évidemment :D)
- De créer des tests unitaires pour tout nouveau code
- d'essayer, progressivement, de rajouter des tests unitaires sur le code existant
Deux ans plus tard, et bien que je n'en aie pas écrit personnellement des masses, il y avait plus de 2000 tests unitaires effectifs, et je peux te jurer que ce n'était pas du luxe, étant donné la complexité du projet!!!
Il n'était en effet pas rare que, voulant résoudre un bug quelconque, on se rende compte que la correction faisait "sauter" deux, trois tests unitaires, voire plus (sans compter ceux que l'on avait mis en place pour tester le scénarion, évidemment :D ) :aie:
La morale qu'il faut retenir de cette histoire, c'est que, si vous voulez éviter les régressions et fournir, autant que faire se peut, un travail de qualité "du premier coup", les tests unitaires peuvent vraiment vous sauver la mise ;)
C'est clair, je suis tout le temps tente de tout mettre en pause pour integrer ces projets de tests et pouvoir en ecrire progressivement.
Malheureusement je pense que j'aurais du mal en pratique, meme si recemment je me suis remis a penser a ca.
Je me recite pour resituer:
Pour l'instant le truc le plus embettant c'est vraiment integrer la suite de test a mon organisation de projets (c'est plein de binaires) actuel en utilisant CMake. Je pense que ca me prendrai un ou deux jours max mais je ne me fais pas confiance sur ce genre de prediction.Citation:
Si je pouvais plannifier suffisamment de temps pour integrer un de ces frameworks, ecrire les tests serait du gateau. Malheureusement, mes projets actuels sont assez massifs et utilisent CMake donc ca necessite de l'organisation, du script etc pour facilement ajouter des tests au fur et a mesure.
Et ca commence par decider quel framework utiliser.
Je ne sais pas encore quand les placer par contre. (comme je suis a mon compte je peu m'organiser comme je souhaite mais le dev avance pas vite quand on est seul sur des tres gros projets)
En fait, si tu as plusieurs binaires et qu'il y a des dépendances de l'un vers l'autre (donc que tu as déjà fait le travail pour que chaque binaire soit une bibliothèque), le travail pour insérer les tests unitaires n'est rien de plus compliqué (*) que... de rajouter un exécutable qui dépend de la bibliothèque en question (de préférence, un projet de test par projet de bibliothèque / binaire)
Si tes projets sont des exécutables, il devrait être "relativement" facile (*) de faire en sorte de créer une bibliothèque (donc: tout sauf le fichier "main" :D) et de faire dépendre le projet de tests de cette bibliothèque ;)
(*) du moins, une fois que la solution de tests est utilisable, s'entend ;)
Mais, de manière générale, plus tu tarderas à mettre ton projet en pause pour intégrer les tests, plus tu verras ta dead line approcher, et moins tu estimeras avoir le temps de t'en occuper :aie:
En plus, il faut rester pragmatique: il est plus facile (et surtout plus efficace) de mettre des tests unitaires en place lorsqu'il n'y a que deux ou trois fonctions, et de créer les tests unitaires pour chaque nouvelle fonction juste avant de l'écrire, que de décider d'écrire les tests unitaires relatifs aux 2500 fichiers qui composent un projet "bien avancé" :P
Comme je le disais la tantôt : au plus tôt tu les intègres, au plus ils te feront gagner de temps ;)
Suite a cette discussion je me suis retrouve hier matin avec une nouvelle classe tres simple et testable et j'ai profite de cette ocasion pour ajouter GTest a mon systeme.
Ca m'auras pris une journee entiere. Le soucis avec GTest c'est que c'est des bibliotheques qu'il faut compiler correctement avec l'ensemble de son projet, du coup avoir la bonne config via Cmake, puis avoir des macros pour declarer les projets de tests et enfin avoir un moyen de lancer les tests facilement.
CMake propose une commande pour enregistrer les tests pour facilement les lancer a partire d'une seule cible/commande. Malheureusement je suis dans un cas ou l'executable de test se trouve dans un dossier different de la ou se trouvent les binaires finaux du projet. Du coup j'ai fais en sorte de lancer les tests dans ce dossier final, mais son path depends de si c'est en Debug, etc. Hors sous CMake c'est assez difficile de faire ce que je viens de dire, je n'ai pas encore trouver comment le faire correctement parcequ'il y a ce que je pense etre des bugs qui m'empechent de le faire ( rapporte la http://www.mail-archive.com/cmake@cm.../msg45812.html ).
Du coup j'ai du ecrire un script python qui lance les tests. Je pense qu'ya encore des details a voir mais bon ca marche.
"yapuka" ecrire des tests.
Note pour les commentaires precedants comparant GTest et Boost.Test : Avec boost, meme si j'aurais eu moins de features, je n'aurais pas perdu du temps a faire en sorte que gtest compile correctement pour le projet en cours (parceque ca depends du linkage et d'autres details qui doivent coller et tout le monde n'utiliser pas le truc par defaut). D'ou ma remarque que GTest est beaucoup plus chiant a mettre en place que Boost.Test (qui est header-only).
Boost.test n'est pas header only.
Par contre, cela se résume à un find boost et find libraries. Cf ces lignes commentées -> https://github.com/LucHermitte/Rasen...eLists.txt#L71 (je n'ai pas de projet en-ligne qui fasse tout pour l'instant)
Concernant débug ou release, avec cmake :
- sous nixoides, je crée deux répertoires : build-r, et build-d et exécute mon "ccmake ../sources" depuis chacun d'eux en positionnant différemment la variable build mode.
- sous windows pour VC++, ccmake génère une solution qui a les options habituelles pour le build en release ou debug.
<edit>
Après, il faut distinguer répertoire de build et répertoires d'install. La hiérarchie de build va matcher celle des sources. Il ne faut pas chercher à la bidouiller, c'est se fatiguer pour rien vu la complexité qu'il y a à sortir des clous avec cmake.
Après, on peut spécifier où vont s'installer les divers binaires et produits associés lors du make install.
</>
Les projets de test se définissent pour ctest.
Si le test doit faire en plus des vérifications d'E/S, il faut définir des macros pour ctest et les utiliser dans ADD_TESTCode:
2
3
4
5
6
Pas besoin de scripts supplémentaires.
Au temps pour moi!Citation:
Envoyé par Luc Hermitte
Mon organisation est differente par necessite. Une fois chaque binaire compile, il est deplace dans un dossier organise de facon a pouvoir tester une version qui est exactement comme une version installee. J'avoue que je ne maitrise pas la partie "install" de cmake (et je n'y connait presque rien en make, j'en ai utilise mais jamais ecris) donc peut etre qu'il y a un moyen de faire pareil plus simplement mais jusqu'ici j'en ai jamais trouve.Citation:
Concernant débug ou release, avec cmake :
- sous nixoides, je crée deux répertoires : build-r, et build-d et exécute mon "ccmake ../sources" depuis chacun d'eux en positionnant différemment la variable build mode.
- sous windows pour VC++, ccmake génère une solution qui a les options habituelles pour le build en release ou debug.
<edit>
Après, il faut distinguer répertoire de build et répertoires d'install. La hiérarchie de build va matcher celle des sources. Il ne faut pas chercher à la bidouiller, c'est se fatiguer pour rien vu la complexité qu'il y a à sortir des clous avec cmake.
Après, on peut spécifier où vont s'installer les divers binaires et produits associés lors du make install.
</>
Citation:
Les projets de test se définissent pour ctest.
Si le test doit faire en plus des vérifications d'E/S, il faut définir des macros pour ctest et les utiliser dans ADD_TESTCode:
2
3
4
5
6
Pas besoin de scripts supplémentaires.
Si si, tu as zape la partie ou le working directory est pas dans le meme dossier. J'ai commence par le code que tu suggeres, ca marchais pas le test crashais par manque de dependances. Regarde le mail dans le liens que j'ai fourni, j'explique qu'il n'y a pas de moyen d'avoir un working directory qui dependente de la configuration de build, tout simplement parceque la variable WORKING_DIRECTORY n'accepte pas de generateur.
Note: j'ai enfin ajoute des tests tout simple a certaines parties du code et ca paye deja pas mal. Donc la journee perdue d'hier est deja rentabilisee.
Un fois de plus, je ne vois pas où est le soucis.
Si ton test doit commencer par un cd ${quelquepart}, change de répertoire. Dans openjpeg ou OTB, tous les tests (qui ne reposent pas sur des TU à la assert_equal, mais des "prog -input=fic_input -output=fic_temp && diff -reference=fic_ref -what=fic_temp") disent où aller chercher les divers fichiers utilisés lors des tests.
Par contre, je pense qu'à vouloir déplacer les fichiers avant le "make install" n'est pas une bonne solution.
Si tu avais lu le liens tu aurais vu que c'est la seconde solution que j'ai tente (faire un cd en premier), mais il y a un bug dans le generateur de CMake pour VS2012 (au moins) qui fait que ca peut pas marcher parcequ'il convertis les paths a l'executable en path relatif au fichier CMake, ce qui rends le cd (ou toute autre forme de changement de path via la commande CMake autre que via WORKING_DIRECTORY) caduque.Citation:
Envoyé par Luc Hermitte
En theory tout ce que tu dis marche, en pratique nope.
Comme je disais, ca devrais effectivement pas etre complique, mais c'est des details qui foutent la merde. Du coup, script. :?
Mais ca devrais pas arriver aux gens normaux je suppose. :aie:
Personnellement, j'utilise un framework personnel. La raison est que les frameworks traditionnellement utilisés (cppunit, Boost.test), même s'ils sont simples, ne correspondent pas à la vision très particulière que j'ai d'un framework de test unitaire. Ce n'est pas tout à fait du NIH.
De plus, la création d'un framework adapté à un projet particulier prends environ 15 minutes, (sachant que les nouveaux projets ne se succèdent pas toutes les heures, ça reste une implémentation peu coûteuse) donc je n'ai jamais vu l'intérêt que peuvent apporter les frameworks du marché. Apprendre à utiliser un framework de test prendra de toute façon au moins le même temps.
A noter que même en C++, j'ai tendance à utiliser un framework procédural, et non pas orienté objet. Ca peut paraître étrange, mais ça reste infiniment plus simple à mettre en oeuvre. C++11 change la donne, même si je n'ai pas encore exploré son potentiel dans ce domaine précis.
J'ai failli faire mon propre framework mais j'ai pas que ca a faire de le maintenir alors j'ai pris une des dependances que j'avais deja.
Je ne comprends pas du tout ce que tu expliques la?Citation:
Envoyé par Emmanuel Deloget
Ben, en gros, un environnement de tests unitaires est relativement simple à mettre en oeuvre lorsqu'on se limite à des fonctions.Citation:
Envoyé par Klaim
Ce n'est jamais qu'une collection de fonction ne prenant aucun paramètre et renvoyant toujours le même type de valeur que l'on va exécuter les unes après les autres.
Si donc tu as une collection de pointeurs de fonction statique, il est assez facile d'écrire une macro qui se chargera de rajouter toutes les fonctions que tu voudra rajouter à tes tests unitaires, quelques macros pour les différents cas (égal, différents, plus grand, plus petit, throw, don't throw) et d'avoir une fonction main qui parcoure cette collection en vérifiant valeurs récupérées ;)
Avec un peu d'habitude, cela ne doit en effet pas prendre beaucoup plus d'un quart d'heure à mettre en place (même si je ne l'ai jamais fait :P) ;)
Mon framework de test principal est codé en "C++ without classes", plutôt qu'en "C with classes" :)Citation:
Envoyé par Klaim
Pour moi, les principaux intérêts de prendre un framework du marché :
- Les tests sont isolés correctement (blocage des exceptions, gestion des assets, débogage fuites mémoire...)
- Des options de rapport de tests existent, et sont compatibles avec des systèmes de build (jenkins...)
- Potentiellement, l'intégration au sein d'un IDE peut aussi faire gagner du temps (d'un click, on relance LE test ayant eu des soucis).
J'ajouterai queCitation:
Envoyé par JolyLoic
- personnellement je prefere ne pas avoir a maintenir le code du dit framework, meme si je suis le seul utilisateur, le moins de code j'ai a gerer moi-meme, le mieu je me porte;
- l'affichage (textuel) du rapport peut etre un peu complique a faire correctement, en particulier si on veut avoir des details, et c'est directement lier aux macros C++ utilisees pour definir les tests. J'ai deja fait de trucs comme ca et juste perdre du temps a avoir une sortie utile la plupart du temps, ca p eut prendr eun temps fou.
Dave Abrahams se plaint de Boost.Test dans ce fil.
Il s'en plaint, à tord ou à raison, ce sera à chacun de se faire sa propre opinion ;)Citation:
Envoyé par oodini
Cependant, les réponse à cette discussion sont presque aussi intéressantes que les remarques qu'il peut faire à son sujet.
Je reconnais volontiers une (bonne) part de vérité dans ce qu'écrit Abrahams, mais il émet des objections propres à sa situation personnelle particulière qui est... d'essayer d'apprendre à ses étudiants à utiliser la bibliothèque.
Et les remarques qu'il fait à cet égard ne concernent en rien les fonctionnalités de boost test, mais bien la documentation et le tutoriel "officiels".
Cependant, s'il fallait décider de refuser en bloc toutes les bibliothèques pour lesquelles l'intégralité de l'interface publique n'est pas documentée ou pour lesquelles il n'existe pas un tutorial officiel reprenant l'ensemble des possibilités des plus simples aux plus avancées, on risquerait de tomber rapidement à court de "bonnes" bibliothèques, tous secteurs confondus (et très certainement dans le domaine des tests unitaires, je crois :S) ;)
Comme je suis actuellement en train de me casser les dents sur ladite bibliothèque (voir ce fil que je viens d'ouvrir), j'aurais tendance à penser comme lui. :)Citation:
Envoyé par koala01
Je ne pense que sa situation soit si personnelle. Tous ceux qui veulent apprendre à utiliser cette bibliothèque sont confrontés aux problèmes qu'il expose. Apprendre Boost.Test, ce n'est pas réservé à ceux qui ont le statut d'élèves.Citation:
Envoyé par koala01
C'est tout aussi important quand on bénéficie d'une exposition telle que celle de Boost.Citation:
Envoyé par koala01