Bonjour a tous.
Est ce que qq un sait comment on fait pour tester des methodes privees avec cppunit ?
Merci
Bonjour a tous.
Est ce que qq un sait comment on fait pour tester des methodes privees avec cppunit ?
Merci
En premier lieu, utilisez un moteur de recherche.
En second lieu, postez sur le forum adéquat !
a- amitié si #define particulier activé
b- maintenir une version deprivatisée de ton fichier d'en-tête (bof)
c- ne tester que les fonctions publiques de la classe qui t'interesse -- c'est le principe des TU il me semble : tester ce qui est dans les interfaces publiques. Peu importe les évolutions d'implémentation.
d- reprendre ton code pour extraire, dans la zone publique d'une autre classe, la partie privée que tu juges à tester.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
D'un point de vue test unitaire, tester les méthodes privées n'a pas de sens.
Bien sûr que ça a un sens.
Tester des méthodes privées, souvent du code factorisé servant à plusieurs algorithmes, permet de s'affranchir de sources d'erreur dans les parties publiques.
Si la méthode privée est correcte, que la méthode publique qui l'utilise ne passe pas un test, on sait qu'il faut :
1/ vérifier que l'appel est conforme à la description de la méthode privée
2/ vérifier qu'il n'y a pas d'effet de bord sur des attributs utilisés (lecture ou écriture) dans celle-ci.
Mais il n'est pas utile de remettre en cause la méthode privée; si son TU est suffisant et prouvé.
Envoyé par VoidSeer
Si je pose la question, c'est que cela a un sens... (plus proche on est de l'erreur, mieux c'est !)D'un point de vue test unitaire, tester les méthodes privées n'a pas de sens.
Ce que je souhaite savoir, c'est s'il existe un autre moyen que de "déprivatiser" les fonctions en question. Sinon, c'est pas grave, je saurai me débrouiller ainsi !
De quel #define parles-tu ?a- amitié si #define particulier activé
Merci encore !
En premier lieu, utilisez un moteur de recherche.
En second lieu, postez sur le forum adéquat !
Ne me faite pas dire ce que je n'ai pas dit. Ecrire un TU pour une méthode privée aide bien
sûr en cas de débogage. Mais strico sensu, un TU n'a d'objet que l'interface d'un classe.
Si la méthode privée en question effectue quelque chose d'utile et complexe à partir de types disponibles par un client, alors autant modifier sa visibilité. Si elle manipule des
données privées de la classe, alors elle n'est pas censée faire partie d'un test unitaire.
Maintenant si c'est vraiment ce que tu souhaites, y'a deux trois bidouilles
L'amitié conditionnelle proposée par LH.
Ou le max du bourrin, que je met ici plus pour rire:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 class Clazz { #ifdef UNIT_TEST friend class ClazzTest; #endif };
Qui en théorie amène un comportement indéfini, mais qui marche en pratique.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 #define private public #include <Class.hpp> // La classe à tester #undef private
OK, ca me va pour le friend (en meme temps, une classe de test amie de celle qu'elle teste, ca me semble correct )
Merci bien.
En premier lieu, utilisez un moteur de recherche.
En second lieu, postez sur le forum adéquat !
Je viens de lire un chapître de livre à ce sujet, Exceptional C++ Style de Stutter, il parle des manières de contourner le "private"
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager