Discussion :

[Klaim]

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.

Note: je n'ai pas vote.

[jblecanard]

- 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++.

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.

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.

Same here, au boulot. Le code reste bien couvert par des tests d'intégration automatisés, heureusement.

[oodini]

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 ?

[koala01]

Salut,

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.

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".

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 )

Mais, à défaut de vivre dans un monde idéal, une autre solution est:

• 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 )
• De créer des tests unitaires pour tout nouveau code
• d'essayer, progressivement, de rajouter des tests unitaires sur le code existant

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 ), 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.

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 )

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

[Klaim]

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:

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.

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.
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)

[koala01]

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" ) 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

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é"

Comme je le disais la tantôt : au plus tôt tu les intègres, au plus ils te feront gagner de temps

[Klaim]

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).

[Luc Hermitte]

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.

Code CMake :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
ADD_EXECUTABLE(UT_Feature1 UT_Feature1.cpp)
TARGET_LINK_LIBRARIES(UT_Feature1 
    MyProjectLib${CMAKE_DEBUG_POSTFIX}
    ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}
    )
ADD_TEST(UT_Feature1 UT_Feature1)

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_TEST

Pas besoin de scripts supplémentaires.

[Klaim]

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)

Au temps pour moi!

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.
</>

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.

Les projets de test se définissent pour ctest.

Code CMake :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
ADD_EXECUTABLE(UT_Feature1 UT_Feature1.cpp)
TARGET_LINK_LIBRARIES(UT_Feature1 
    MyProjectLib${CMAKE_DEBUG_POSTFIX}
    ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}
    )
ADD_TEST(UT_Feature1 UT_Feature1)

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_TEST

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.

[Luc Hermitte]

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.

[Klaim]

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.

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.
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.

[Emmanuel Deloget]

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.

[Klaim]

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.

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.

Je ne comprends pas du tout ce que tu expliques la?

[koala01]

Je ne comprends pas du tout ce que tu expliques la?

Ben, en gros, un environnement de tests unitaires est relativement simple à mettre en oeuvre lorsqu'on se limite à des fonctions.

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 )

[Emmanuel Deloget]

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?

Mon framework de test principal est codé en "C++ without classes", plutôt qu'en "C with classes"

[JolyLoic]

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).

[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 que
- 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.

[oodini]

Dave Abrahams se plaint de Boost.Test dans ce fil.

[koala01]

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

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)

[oodini]

Il s'en plaint, à tord ou à raison, ce sera à chacun de se faire sa propre opinion

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.

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.

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.

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".

C'est tout aussi important quand on bénéficie d'une exposition telle que celle de Boost.