[Cppunit] test de methodes privees

Bonjour a tous.
Est ce que qq un sait comment on fait pour tester des methodes privees avec cppunit ?

Merci :)

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.

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

Citation:

---

Envoyé par VoidSeer

D'un point de vue test unitaire, tester les méthodes privées n'a pas de sens.

---

Citation:

---

D'un point de vue test unitaire, tester les méthodes privées n'a pas de sens.

---

Si je pose la question, c'est que cela a un sens... (plus proche on est de l'erreur, mieux c'est !)

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 !

Citation:

---

a- amitié si #define particulier activé

---

De quel #define parles-tu ?

Merci encore !

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.

Code:

---

1 2 3 4 5 6

class Clazz { #ifdef UNIT_TEST friend class ClazzTest; #endif };

---

Ou le max du bourrin, que je met ici plus pour rire:

Code:

---

1 2 3

#define private public #include <Class.hpp> // La classe à tester #undef private

---

Qui en théorie amène un comportement indéfini, mais qui marche en pratique.

OK, ca me va pour le friend (en meme temps, une classe de test amie de celle qu'elle teste, ca me semble correct ;) :lol: )

Merci bien.

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"