Test Unitaire avec la STL

Version imprimable

11/04/2019, 18h14
AoCannaille

Test Unitaire avec la STL

Bonjour à tous,

J'aimerais savoir s'il y a un framework, même simpliste, inclut dans les dernières version de C++ ( par dernières, j'entends après C++11)

Mes conditions de travail font que je ne peux rien (absolument rien) changer à mon environnement de développement. J'ai donc accès à un gcc 6.5 et rien d'autre.

J'ai cherché un peu sur C++ références, sur wiki, la fac DVP... et je ne tombe que sur des frameworks externes...

J'espère que c'est parce que j'ai mal cherché, parce que pour l'instant j'en conclu qu'il n'y a rien de prévu dans la STL :(

Est-ce que quelqu'un qui suit mieux les actualités du langage peut me confirmer/infirmer cette impression très désagréable?

Merci d'avance :)
11/04/2019, 18h21
Bousk

Non il n'y a pas de trucs de tests dans la std.
Il existe plusieurs libs de tests dont je ne me souviens plus les noms...
Après ça dépend ce que tu veux et veux faire ? Pour mes dévs simples, de simple macro me suffisent.
12/04/2019, 10h25
AoCannaille

Citation:

Envoyé par Bousk

Non il n'y a pas de trucs de tests dans la std.
Il existe plusieurs libs de tests dont je ne me souviens plus les noms...
Après ça dépend ce que tu veux et veux faire ? Pour mes dévs simples, de simple macro me suffisent.

Merci pour la triste confirmation :)

Je voulais éviter les macros parce qu'elles ne sont pas type safe et que ça date d'un autre temps ^^

Bon bah comme d'hab dans les environnements limités, la b*te et le couteau ^^
12/04/2019, 14h14
Bousk

Les macros ne datent pas d'un autre temps et permettent des choses impossible autrement (comme stringifier n'importe quoi).
La plupart des frameworks de TU utilisent des macros.
15/04/2019, 09h18
AoCannaille

J'en ai conscience, mais entre utiliser des macro robustes et développer les miennes en sachant que ça reste toujours plus ou moins indébuggable, j'aurais préféré avoir un truc déjà prêt :)
15/04/2019, 16h52
koala01

Salut,

Ceci dit, si toi, tu n'as pas le droit de modifier ton système (ce que l'on peut comprendre du point de vue du patron, mais qui pose quand même pas mal de problème du point de vue du développeur :D), il te reste toujours la possibilité de "faire ch...er" celui qui a le droit de le faire pour qu'il t'installe un environnement "correct"; par exemple, en insistant pour qu'il t'installe boost, googletest ou, "plus simplement" Catch2 en précisant que tu ne pourras rien faire de bon dans qu'elles n'auront pas été installées ;) .

Et, qui sait, les deux premières bibliothèques sont assez difficiles à installer pour que tu puisse faire comprendre au responsable que, s'il veut que tu puisse travailler "correctement", sans devoir venir le "faire chier" à chaque fois que tu as besoin d'un outil particulier (si cela ne suffit pas, demande lui juste après de t'installer CMake, et, après, Doxygen et GraphViz, et enfin git juste pour rire :D ) et attendre qu'il ait le temps de s'occuper de ta demande (tout à fait raisonnable et nécessaire), il serait utile qu'il comprenne que tu n'est pas vraiment le premier clampain auquel il fournit un ordinateur, et qu'il devra "te faire confiance" pour ne pas aller installer toi-même les outils dont tu as besoin (qui sont tout à fait spécifiques par rapport à n'importe quel employé) sans aller installer n'importe quelle cochonnerie,

En tant que développeur, il faut bien comprendre (et arriver à faire comprendre au responsable) que tu as besoin d'utiliser des outils et des éléments dont les "utilisateurs classiques" n'ont jamais même entendu parler, et que ces besoins apparaissent souvent au fil du temps.

Plutôt que de t'engueuler simplement avec le responsable, je te proposes de lui en faire prendre conscience "en douceur", en le faisant chier pour qu'il installe ces outils au fur et à mesure ;).

Et si cela ne suffit pas, il te reste toujours le choix de changer de travail pour arriver dans une société qui sera consciente de tes besoins spécifiques :D .

Car il n'y a rien à faire, j'ai travaillé dans des grandes boîtes, qui sécurisaient elles aussi "autant que faire ce peut" les ordinateurs qu'elles mettent à disposition de leur employés. Mais toutes avaient bien compris que le développeur n'est pas un utilisateur lambda, et qu'il doit disposer d'une "certaine liberté" de mouvement.

La possibilité d'installer (ou de mettre à jour) des outils spécifiques et, surtout, de bibliothèque tierce fait partie de cette liberté de mouvement et des besoins qui lui sont propres pour pouvoir faire son travail correctement ;)
15/04/2019, 22h50
AoCannaille

Mon domaine d'activité implique la plus grande sécurité y compris dans les postes de développements. Je ne suis pas connecté à internet par exemple. Les COTS sont analysés et acceptés au compte gouttes après code review attentive (ce qui génère un retard incroyable sur nos versions de logiciels...). C'est bien pour ça que je cherchais une solution "built-in". Je me vois mal demander une dérog' à l’État Major ^^'

Je suis évidement d'accord avec toi, et j'ai utilisé ta technique auparavant avec un certain succès dans mes missions précédentes, mais là, c'est juste impossible.

J'apprécie ton soutien, évidement ;) Et j'encourage tous ceux qui lisent ce message à appliquer ta proposition! :mrgreen:
16/04/2019, 17h23
koala01

Hé bien, pour le coup, ca me dépasse...

On dit souvent de l'armée que c'est la "grande muette", mais, dans le cas présent, ce serait plutôt "la grande handicapée" :D

Car je comprends très bien que certains ordinateurs (même ceux de développement) puissent contenir des données sensibles, et qu'il faille impérativement éviter tout risque de fuites vers l'extérieur.

Mais l'état major devrait arriver à comprendre que le boulot du développeur est un boulot tout à fait particulier, qui éprouve des besoins tous particuliers, dont, ceux de disposer de certains outils,qui ne peuvent être utilisés correctement que si les ordinateurs de développement peuvent discuter entre eux.

Quitte à créer une "zone démilitarisée" (tu me dira que qu'est un comble pour l'armée), un réseau strictement interne, qui n'a aucun lien avec l'extérieur, et à y mettre -- après les vérifications d'usage, cela va de soit -- les dépôts des outils dont les développeurs auront besoin (un build server, un gestionnaire de versions, les bibliothèques dont il a besoin), l'état major devrait quand même se rendre compte que les développeurs -- des BAC+4 à BAC+7 pour la plupart -- ne sont pas vraiment les recrues de bases auxquelles on demande de débrancher le cerveau lors de l'instruction, et pour lesquelles toutes les décisions sont prises.

Mais il ferait bien de se rendre compte que, s'il veut des outils efficaces, qui tuent leur ennemis et non ses propres troupes, développés en interne, il doit laisser "un minimum de latitude" à ses développeurs ;)

Enfin, j'ai bien conscience que je n'y changerai rien et toi non plus... Mais c'est bien dommage ;)

Citation:

Envoyé par AoCannaille

J'en ai conscience, mais entre utiliser des macro robustes et développer les miennes en sachant que ça reste toujours plus ou moins indébuggable, j'aurais préféré avoir un truc déjà prêt :)

Ben, voilà :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 #include <iostream> #ifdef CHECK # error CHECK is already defined. #endif #define CHECK(cond) \ if((cond) == false) { \ ++errorCount; \ std::cerr << "Fail: " << __func__ << ": " << #cond << '\n'; \ } else \ static_cast<void>(0)
Exemple de code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 #include <iostream> #ifdef CHECK # error CHECK is already defined. #endif #define CHECK(cond) \ if((cond) == false) { \ ++errorCount; \ std::cerr << "Fail: " << __func__ << ": " << #cond << '\n'; \ } else \ static_cast<void>(0) int test_add() { int errorCount = 0; CHECK(1 + 2 == 3); CHECK(4 + 5 == 9); return errorCount; } int test_minus() { int errorCount = 0; CHECK(10 - 1 == 9); CHECK(1 - 10 == -9); return errorCount; } int test_all() { int errorCount = 0; errorCount += test_add(); errorCount += test_minus(); return errorCount; } int main() { int errorCount = 0; errorCount += test_all(); if(errorCount == 0) std::cout << "Success."; else std::cout << "Error count: " << errorCount << '.'; return errorCount; }
Il n'y a pas autant de fonctionnalités que dans un framework de tests unitaires, mais ça marche et ça compile vite.
Dans mon code perso, j'ai fini par laisser tomber Boost.Test dont le temps de compilation excessif dissuadait de recompiler les tests unitaires.
Je ne sais pas quel est le meilleur framework de tests unitaires en C++. Mais je rejoins Bousk sur un point : parfois, de simples macros suffisent.

16/04/2019, 22h20
AoCannaille

Citation:

Envoyé par koala01

Quitte à créer une "zone démilitarisée" (tu me dira que qu'est un comble pour l'armée), un réseau strictement interne, qui n'a aucun lien avec l'extérieur, et à y mettre -- après les vérifications d'usage, cela va de soit -- les dépôts des outils dont les développeurs auront besoin (un build server, un gestionnaire de versions, les bibliothèques dont il a besoin)

Je te rassure, c'est ce qu'on a. Sauf qu'il n'y a pas de framework de test C++ dedans ;-)
Les demandes prennent un temps fou (ne serai-ce que pour être traitées sérieusement, sans même parler de l'inspection ensuite...), j'aurais fini ma mission avant que cela arrive.

@pyramidev, merci beaucoup :) Au final, j'étais arrivé à une solution similaire aprés avoir lu cet article concernant un framework de test macroless et du coup en ayant abandonné l'idée car beaucoup trop verbeux ^^
En effet, le ~~micro~~/~~nano~~/pico-framework de test créé rend la syntaxe vraiment simple pour les cas simples.
16/04/2019, 23h35
jo_link_noir
Citation:

Envoyé par Pyramidev

Dans mon code perso, j'ai fini par laisser tomber Boost.Test dont le temps de compilation excessif dissuadait de recompiler les tests unitaires.

Si on utilise Boost.Test sous forme de bibliothèque dynamique, le temps de compilation est drastiquement réduit.

Un .cpp qui contient
Code:

1 2 3 4 5 #define BOOST_AUTO_TEST_MAIN #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test_monitor.hpp> #include <boost/test/included/unit_test.hpp>
Et les tests compilés avec -DBOOST_TEST_DYN_LINK et une valeur pour BOOST_TEST_MODULE.

La doc indique autre chose, mais je ne sais plus pourquoi je fais comme ça :/

Parmi les autres frameworks de test, il y a Doctest qui est header-only. Mais à moins d'avoir beaucoup de check, il est plus lent à compiler que boost.test en bibliothèque dynamique.

Pour les macros, actuellement je pense que c'est le meilleur moyen pour avoir des informations sur la source: fichier, numéro de ligne, condition/code en faute et affichage des valeurs dans une condition en échec. Par exemple, Boost.Test (et Doctest) affiche quelque chose comme test.cpp(12): error: in "specialTheory": check m * c * c == e has failed [2 * 4 * 4 != 31], et il n'existe aucun moyen d'avoir la même sans macro. Il y a bien std::source_location (expérimental), mais celui-ci ne contient pas la ligne des sources.

Note: pour Boost.Test, il faut compiler les tests avec -DBOOST_TEST_NO_OLD_TOOLS pour avoir les valeurs dans l'affichage. Cela modifie aussi la manière dont les char* sont comparés: la valeur du pointeur est comparé, plus le contenu.