tester une partie de son code

Version imprimable

25/08/2017, 23h56
baring

tester une partie de son code

Bonsoir,

Je suis nouveau et je débute en programmation sur C++. J'aimerais savoir s'il est possible de tester juste une partie de son code pour voir s'il effectue bien ce qu'on lui demande. Je m'explique, par exemple, dans mon int main() je veux approcher le cosinus d'un nombre par un développement en série mais j'ai besoin de certaine fonctions annexes tel qu'une fonction factorielle entre autre et je voudrais juste tester cette fonction pour voir si elle est juste. Est-il possible de faire ça ? Parce que ça m'embête de devoir taper tout mon programme et seulement après la compilation de m'apercevoir que toutes mes fonctions sont mal codées...

Merci de votre aide :)
26/08/2017, 00h34
Detenu-1_0-J_6_4

Salut, je ne sais pas comment tu compiles ton code, mais à priori je dirais, utilise ton Debugger c'est très facile. si tu ne sais pas comment t'en servir, recherche sur le net Debugger de mon «IDE» IDE ici est pour l'outil de compilation que tu utilises. Bonne suite

Bonjour,

Voici un bout de code qui répond au besoin :
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 43 44 45 46 47 #include <iostream> int factorielle(int param) { // code } int puissance(int x, int y) { // code } void tester_factorielle() { if(factorielle(0) != 1) std::cout << __func__ << " : factorielle(0) aurait du valoir 1 mais vaut " << factorielle(0) << ".\n"; if(factorielle(1) != 1) std::cout << __func__ << " : factorielle(1) aurait du valoir 1 mais vaut " << factorielle(1) << ".\n"; if(factorielle(2) != 2) std::cout << __func__ << " : factorielle(2) aurait du valoir 2 mais vaut " << factorielle(2) << ".\n"; if(factorielle(5) != 120) std::cout << __func__ << " : factorielle(5) aurait du valoir 120 mais vaut " << factorielle(5) << ".\n"; } void tester_puissance() { if(puissance(55, 0) != 1) std::cout << __func__ << " : puissance(55, 0) aurait du valoir 1 mais vaut " << puissance(55, 0) << ".\n"; if(puissance(0, 55) != 0) std::cout << __func__ << " : puissance(0, 55) aurait du valoir 0 mais vaut " << puissance(0, 55) << ".\n"; if(puissance(-2, 9) != -512) std::cout << __func__ << " : puissance(-2, 9) aurait du valoir -512 mais vaut " << puissance(-2, 9) << ".\n"; } void lancer_les_tests_unitaires() { std::cout << "Lancement des tests unitaires...\n"; tester_factorielle(); tester_puissance(); std::cout << "Fin des tests.\n"; } int main() { lancer_les_tests_unitaires(); return 0; }
Écrire des tests pour vérifier le bon fonctionnement des morceaux du programme est une très bonne initiative.
De tels tests s'appellent des tests unitaires.
Quand on décide de modifier le code mais que l'on craint que, en faisant cela, on ajoute un bogue par étourderie, il suffit de lancer la batterie des tests unitaires. Si on a fait une bêtise, on le verra vite.
Tu remarqueras que je n'affiche que les tests qui échouent. C'est volontaire. Le jour où il y aura plusieurs centaines de tests unitaires, on ne voudra pas lire à chaque fois un gros paquet de texte pour vérifier si tout a bien réussi.

Cela dit, dans du code plus soigné mais plus technique, pour écrire des tests unitaires, on écrit un code moins lourd que celui que j'ai écrit. Par exemple, à la place de :
Code:

1 2 if(factorielle(5) != 120) std::cout << __func__ << " : factorielle(5) aurait du valoir 120 mais vaut " << factorielle(5) << ".\n";
on écrirait plutôt un code du genre :

Code:

VERIFIER_VALEUR_REELLE_EGALE_VALEUR_ATTENDUE(factorielle(5), 120);

avec VERIFIER_VALEUR_REELLE_EGALE_VALEUR_ATTENDUE une macro-fonction qui fait le boulot de comparaison et de formatage du message d'erreur en cas d'inégalité.

Et dans du code encore meilleur, au lieu de réinventer la roue en bricolant des macro-fonctions comme VERIFIER_VALEUR_REELLE_EGALE_VALEUR_ATTENDUE, on utiliserait un framework de tests unitaires, comme Boost.Test.

Mais si tu débutes alors, les frameworks de tests unitaires, ce sera pour plus tard. En attendant, tu peux faire des tests unitaires avec du code un peu lourd mais accessible comme celui que j'ai écrit au début de mon message.

26/08/2017, 01h20
baring

Citation:

Envoyé par Dr_Frankenstein

...

Merci de ton aide Dr_Frankenstein. Alors moi j'utilise geany et pour compiler je fais simplement F9 puis F5 pour exécuter le programme et ouvrir ma console. Donc si j'ai bien compris "debugger" ça permet d'identifier mes fautes de codage ? mais si la fonction que j'ai tapé est juste mais qu'elle ne fait pas ce que j'attend y a pas un moyen de la tester à part ?
26/08/2017, 01h25
baring

Citation:

Envoyé par Pyramidev

...

Merci Pyramidev c'est exactement ça que je cherchais ! :)
26/08/2017, 01h34
Detenu-1_0-J_6_4

Le test avec le Test unitaire c'est une très bonne méthode dont il faut prendre l'habitude très tôt; mais ce que moi je conseillerai, c'est d'utiliser cette méthode que lorsqu'il s'agit de programme suffisamment costaud et difficilement debuggable. et puis le debuggeur aussi avec le temps d'aidera aussi à mieux connaître et à apprécier ton IDE ;)

Comme l'a dit Pyramidev, faire un "script" est une solution rapide à coder.
Et tu as l'avantage de la ligne de commande: tu peux l'exécuter n'importe quand et rapidemment.

Après tu peux chercher des bibliothèques comme Google Test. Mais fais attention :mrgreen:, c'est rempli de buzzword: dummy, fake, stub, mock, spy, ... (<- la différence est très subtile, et moi par exemple, j'ai déjà utilisé certains sans le savoir ;))

Ensuite je ne suis pas d'accord avec Pyramidev sur l'affichage d'un résultat :mrgreen:. Un résultat doit dire si il a réussi ou échoué, quel est le but du test et avoir un compteur.
Donc un test comme ceci; par exemple, pour tester la validation d'une chaîne de caractères: (ma fonction validate_text_input doit prendre plus de paramètres, mais j'ai simplifié pour l'exemple)
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 void test_validate_text_input() { int count = 1; std::printf("%02d - validate_text_input - test empty str : %s", count, (( validate_text_input("") )? "success": "fail")); ++count; // On inverse le retour pour savoir si la fonction a le bon comportement std::printf("%02d - validate_text_input - length str < min : %s", count, ((!validate_text_input("123"))? "success": "fail")); ++count; std::printf("%02d - validate_text_input - length str == min : %s", count, (( validate_text_input("12345") )? "success": "fail")); ++count; // On inverse le retour pour savoir si la fonction a le bon comportement std::printf("%02d - validate_text_input - length str > max : %s", count, ((!validate_text_input("123456789012345678901234567890123"))? "success": "fail")); ++count; std::printf("%02d - validate_text_input - length str == max : %s", count, (( validate_text_input("12345678901234567890123456789") )? "success": "fail")); ++count; std::printf("%02d - validate_text_input - no error, only alpha : %s", count, (( validate_text_input("1234567890") )? "success": "fail")); ++count; std::printf("%02d - validate_text_input - no error, ascii, lower case : %s", count, (( validate_text_input("abcdefghiklmnopqrstuvxyz") )? "success": "fail")); ++count; std::printf("%02d - validate_text_input - no error, ascii, upper case : %s", count, (( validate_text_input("ABCDEFGHIKLMNOPQRSTUVXYZ") )? "success": "fail")); ++count; std::printf("%02d - validate_text_input - no error, special char : %s", count, (( validate_text_input("082avbd/-*?@") )? "success": "fail")); ++count; // On inverse le retour pour savoir si la fonction a le bon comportement std::printf("%02d - validate_text_input - error pos 5 : %s", count, ((!validate_text_input("082a²vbd/-*?@"))? "success": "fail")); ++count; // ... }
Et le dernier point, il faut réussir autant que faire se peut que chaque résultat fasse moins de 80 caractères pour ne pas avoir de retour à ligne dans la console.
Et le must, l'alignement en colonnes (quelques espaces par ci par là) pour qu'en un coup d’œil voir les tests échoués plus facilement ;)

Citation:

Envoyé par foetus

Un résultat doit dire si il a réussi ou échoué, quel est le but du test et avoir un compteur.

J'ai oublié un truc important :oops: :oops: : pourquoi il échoue

Pour reprendre le test de ma fonction validate_text_input:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
//  the simplified test
//  On inverse le retour pour savoir si la fonction a le bon comportement
//  std::printf("%02d - validate_text_input - error pos 5 : %s", count, ()? "success": "fail"));
// ++count;
 
//  the real test
    short pos;
    t_VALIDATION_ERROR error; // enum type
 
    if (!validate_text_input("082a²vbd/-*?@", error, pos)) {
        if (error == VALIDATION_ERROR_CHAR_AT) {
            if (pos == 5) {
                std::printf("%02d - validate_text_input - error pos 5 : success", count);
            } else {
                std::printf("%02d - validate_text_input - error pos 5 : fail (bad pos: %s)", count, pos);
            }
        } else {
            std::printf("%02d - validate_text_input - error pos 5 : fail (bad error: %s)", count, convert_error_to_str(error));
        }
    } else {
        std::printf("%02d - validate_text_input - error pos 5 : fail (error: success)", count);
    }
    +count;

27/08/2017, 10h47
Bktero

J'utilise Google Test et il est simple à mettre en oeuvre. La problématique décrite dans le premier message est exactement résolue par des tests unitaires. Il ne faut pas hésiter à en faire :)
27/08/2017, 10h52
Bktero

Citation:

Envoyé par Dr_Frankenstein

Le test avec le Test unitaire c'est une très bonne méthode dont il faut prendre l'habitude très tôt; mais ce que moi je conseillerai, c'est d'utiliser cette méthode que lorsqu'il s'agit de programme suffisamment costaud et difficilement debuggable. et puis le debuggeur aussi avec le temps d'aidera aussi à mieux connaître et à apprécier ton IDE ;)

Ces deux choses n'ont rien à voir.

Les tests unitaires valident du code (s'ils sont bien faits).

Le debuger est un outilo pour mieux comprendre l'exécution d'un code, souvent dans le but de comprendre pourquoi il ne fonctionne pas comme souhaité.

Que débogguer si tu n'as pas un programme de tests ? Le debuger peut justement servir à comprendre pourquoi tes tests unitaires sont en échec.

Inutile de sortir l'artillerie lourde de tests unitaires dans un premier temps.
Perso je me content d'une simple macro pour commencer #define ASSERT(x) do { if (x) { std::cout<<"[OK]"<<#x<<std::endl; } else { std::cout<<"[FAILURE] " << #x <<std::endl; } } while(0)
Puis tu peux affiner autant que tu veux selon ce que tu tests (si je test que des égalités, cette seule macro me suffit)
Code:

1 2 3 4 #define ASSERT_OK(x, y, op) do { std::cout<<"[OK] "<< #x <<op<< #y << std::endl; } while(0) #define ASSERT_KO(x, y, op) do { std::cout<<[FAILURE] " #x <<op<< #y << std::endl; } while(0) #define ASSERT_EQUAL(x, y) do { const auto _x = (x); const auto _y = (y); if (_x == _y) { ASSERT_EQUAL_OK(x, y, "=="); } else { ASSERT_EQUAL_KO(x, y, "!="); } } while(0) #define ASSERT_SUP(x, y) do { const auto _x = (x); const auto _y = (y); if (_x > _y) { ASSERT_EQUAL_OK(x, y, ">"); } else { ASSERT_EQUAL_KO(x, y, "<="); } } while(0)
Puis tu peux ajouter de la couleur, rouge en cas d'échec par exemple, etc...
https://stackoverflow.com/questions/...console-with-c

Tu peux aller très loin, d'où l'existence de frameworks de test entiers, à toi de voir ce que tu veux faire.

28/08/2017, 09h39
ternel

En très résumé, non, on ne peux pas tester une partie d'un programme, sans le modifier spécifiquement pour ça.

Par contre, on peut écrire un autre programme (c'est à dire une autre fonction main), qui se sert uniquement de la partie à tester du code du premier.
C'est ce que font tous les frameworks de test unitaire.

L'intérêt du framework de test unitaire, c'est de fournir des outils spécifiques pour ça, permettant de n'écrire pratiquement que les instructions à tester.
29/08/2017, 10h00
Detenu-1_0-J_6_4

Citation:

Envoyé par Bktero

Ces deux choses n'ont rien à voir.

Les tests unitaires valident du code (s'ils sont bien faits).

Le debuger est un outilo pour mieux comprendre l'exécution d'un code, souvent dans le but de comprendre pourquoi il ne fonctionne pas comme souhaité.

Que débogguer si tu n'as pas un programme de tests ? Le debuger peut justement servir à comprendre pourquoi tes tests unitaires sont en échec.

Jusqu'ici je n'ai déjà eu besoin de test unitaire qu'en Java à cause de son Garbage Collector qui me simplifie la tache, mais en C++ et C j'utilise couramment mon simple debugger pour comprendre effectivement bien comment tout se passe et du cout je peux me passer des tests unitaires. Mais attention je ne refute pas la puissance du test unitaire, je dis juste que le debugger peut avoir une autre utilisation que debugger :mrgreen:
29/08/2017, 10h28
foetus

Citation:

Envoyé par Jack_La_Rancoeur

je dis juste que le debugger peut avoir une autre utilisation que debugger

Tout comme, les tests unitaires ont une autre utilisation que tester :mrgreen: : conception et documentation

Et surtout que le debugger a ces limites :aie:, comme avec les contextes "multi-threadés" ou heisenbug
29/08/2017, 10h31
ternel

Certes, mais un test unitaire est automatisé.
Tu sais ce que tu testes, comment, et tu peux le tester à nouveau dans les mêmes conditions.

Et cela, un débuggeur ne peut pas le garantir.

Cela dit, je suis toujours à la recherche d'un framework de test qui me permettrait de tester aisément std::map.
Par exemple, Google Test est limité à un seul paramètre template varié.

Et de même, il ne gère pas facilement les tests des aliases de type.
29/08/2017, 11h18
Bousk

Citation:

Envoyé par Jack_La_Rancoeur

Jusqu'ici je n'ai déjà eu besoin de test unitaire qu'en Java à cause de son Garbage Collector qui me simplifie la tache, mais en C++ et C j'utilise couramment mon simple debugger pour comprendre effectivement bien comment tout se passe et du cout je peux me passer des tests unitaires. Mais attention je ne refute pas la puissance du test unitaire, je dis juste que le debugger peut avoir une autre utilisation que debugger :mrgreen:

Faut arrêter le délire. Et la relation entre GC et test unitaire... juste aucune. :weird:
Quand tu debugges tu testes pas, tu cherches un bug. Tu vérifies que les appels spécifiques sont corrects mais tu ne vérifies qu'un ou plusieurs chemin(s) rapidement.
Un test c'est pour vérifier que ta fonction retourne les valeurs attendues pour les valeurs d'entrée connues. Quand tu veux tester 5000000x, du multi-threading ou un truc un peu "aléatoire" tu vas pas y aller au debugger, de même que quand tu changes un morceau tu vas pas aller repasser au debugger tous tes appels dans l'ensemble du programme. Sauf à ce que ton programme soit d'un millier de ligne de code et ridiculement petit. En ce cas tu peux aussi debugger au printf pour ce que ça m'importe.
Sans parler des machines d'intégration et tests.
29/08/2017, 11h37
Detenu-1_0-J_6_4

Les Tests unitaires, je ne refûte pas la puissance, mais comment tu fais par exemple pour tester un truc que tu ne peux pas tester? ce n'est pas dans tous les codes qu'il y'a des Assertions, bien sur c'est toujours possible de se casser un peu et de contourner pour pouvoir y ajouter une assertion. je prends par exemple sur la production d'interface avec le QML de Qt qui est un langage essentiellement descriptif, Pour ce que je sache et de ma petite experience je peux dire que si tu n'y vas pas au débuggeur alors c'est presque mort. Des tests unitaires sont aussi possibles mais difficilement réalisable (pas impossible mais seulement difficilement reailsable) parfois selon le contexte et le debugger s'offre comme une bonne alternative.
En ce qui concerne la taille du programme qui pourrait etre vu comme une faiblesse du debugger moi je dirai que tout dépend de comment tu conçois ton programme. Moi par exemple j'ai pris la résolution de ne plus écrire des fichiers de plus de 100 à 200 lignes de codes (en théorie :mrgreen:). De ce fait je débugge plus facilement.

Quant au Multithreading, comme je l'ai dit, je n'ai pas une trop grande experience, jusqu'ici j'ai juste en fait avec le C et j'avais effectivement utilisé les tests unitaires donc vous devez certainement avoir raison

Bref tout ceci j'ai proposé parce que la question de départ était en rapport avec une fonction plus au moins petite, et un debugger ou des std::cout ou ::cerr aurait fait l'affaire. Je veux juste aussi dire que le debuggeur peut devenir très puissant quand on sait bien s'en servir , quite à s'en servir pour s'assurer du bon fonctionnement d'un code.
29/08/2017, 11h46
ternel

Je travaille sur une bibliothèque de plus de 100 fichiers de moins de 200 lignes (il y a 45 classes métiers…)
Comment la tester?
Comment m'assurer qu'elle n'a pas de bug alors même que je n'ai pas de main?

Et pour ta conclusion "c'était pas la peine de sortir l'artillerie"…

Sur développez.com, notre philosophie est de donner des réponses de qualité, et satisfaisante dans un cadre professionnel.

A la question "Comment tester une partie de son code.", la réponse est "Par (au moins) un test unitaire dédié à cette partie du code".
Le choix de assert, cout ou cerr, ou un système de test unitaire dédié est accessoire, c'est un détail technique.
Nous y avons répondu plusieurs fois par "choisis l'outil qu'il te plaira".

La réponse n'est pas sur la technique, mais la méthode.
29/08/2017, 11h50
Bousk

Citation:

Envoyé par Jack_La_Rancoeur

comment tu fais par exemple pour tester un truc que tu ne peux pas tester?

je te le fais pas dire.. explique-nous ton secret qui rend le debugger idéal pour tester l'intestable :roll:

Citation:

Envoyé par Jack_La_Rancoeur

ce n'est pas dans tous les codes qu'il y'a des Assertions, bien sur c'est toujours possible de se casser un peu et de contourner pour pouvoir y ajouter une assertion.

Se casser un peu pour appuyer sur "Enter" et ajouter une ligne d'assert ? Trop dur ? :weird:
Et un assert ça n'a rien à voir avec des tests.

Citation:

Envoyé par Jack_La_Rancoeur

je prends par exemple sur la production d'interface avec le QML de Qt qui est un langage essentiellement descriptif, Pour ce que je sache et de ma petite experience je peux dire que si tu n'y vas pas au débuggeur alors c'est presque mort. Des tests unitaires sont aussi possibles mais difficilement réalisable (pas impossible mais seulement difficilement reailsable) parfois selon le contexte et le debugger s'offre comme une bonne alternative.

Et tu testes quoi au juste sur le QML ? Si tu utilises Qt et le QML, c'est à eux de le tester et debugger, pas à toi.

Citation:

Envoyé par Jack_La_Rancoeur

En ce qui concerne la taille du programme qui pourrait etre vu comme une faiblesse du debugger moi je dirai que tout dépend de comment tu conçois ton programme. Moi par exemple j'ai pris la résolution de ne plus écrire des fichiers de plus de 100 à 200 lignes de codes (en théorie :mrgreen:). De ce fait je débugge plus facilement.

Encore une fois hors sujet. Quel rapport avec la taille d'un fichier ? Tu vas juste avoir 10M fichiers au lieu de 10k, je vois pas bien l'évolution et la plus grande facilité à tester..

Citation:

Envoyé par Jack_La_Rancoeur

Je veux juste aussi dire que le debuggeur peut devenir très puissant quand on sait bien s'en servir , quite à s'en servir pour s'assurer du bon fonctionnement d'un code.

Ton debugger va te permettre de tester 1 truc 1 fois. C'est... nul en fait. Tout juste bon à vérifier que ton implémentation répond à ce truc spécifiquement, ce n'est en rien un test un minima probant.