Discussion :

[Invité]

Bonjour,

j'ai actuellement une question assez bête, mais je suis pas assez rodé sur le langage pour trouver moi même la réponse...

J'ai une certaine classe, mettons NeuronFactory, qui me retourne des Neuron*.
Now, j'aimerais tester une certaine propriété (la propriété value bien mise à 10 de mon neurone de type Neuron*), mais qui est protégée.

Du coup, j'ai qqch dans le genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
class NeuronFactory{
  Neuron *getNeuron(int value){return new Neuron(value);}
};
 
class Neuron{
  public:
    Neuron(int a):value(a){}
  protected:
    int value;
};
 
class NeuronTest:public Neuron{
  //using Neuron::value; n'y change rien
  NeuronTest(Neuron* n):Neuron(n->value){} //Erreur ici, value is protected
  int getValue(){return value;}
};
void test(){
  //un test qui vérifie que la value est bien settée par le neurone
  NeuronFactory n;
  Neuron* neuron = n->getNeuron(10);
  NeuronTest* neuronTest = new NeuronTest(neuron);
  Tester.is(neuronTest->getValue(), 10);
}

Mon idée, c'est que lorsqu'on accède depuis une classe à un objet de la même classe, alors les valeurs sont "publiques", typiquement NeuronTest(NeuronTest b) permet d'accéder aux propriétés de b. Mais ici, NeuronTest bien que fille de Neuron ne permet pas d'accéder aux propriétés de Neuron. Même en précisant le using Neuron::value;

Avez vous une idée?

[Emmanuel Deloget]

Mon idée, c'est que lorsqu'on accède depuis une classe à un objet de la même classe, alors les valeurs sont "publiques", typiquement NeuronTest(NeuronTest b) permet d'accéder aux propriétés de b. Mais ici, NeuronTest bien que fille de Neuron ne permet pas d'accéder aux propriétés de Neuron. Même en précisant le using Neuron::value;

Avez vous une idée?

Pourquoi est-ce qu'une classe de test aurait besoin de connaitre l'invariant d'une autre classe ? Le test est là pour tester la validité des pré-conditions / post-conditions, ainsi que la validité du résultat.

SI tu passe outre cette remarque:
* Ta classe de test n'hérite pas de ta classe. C'est une très mauvaise chose.
* Si tu souhaite vraiment avoir un accès à l'invariant de ta classe, alors ta classe de test est une classe amie de ta classe testée.

Je préviens quand même que cette dernière solution, bien que répondant à tes attentes, n'est PAS une bonne solution. La classe doit être designée de manière à toujours dissimuler son invariant, et la classe de test a pour but de tester une interface. Tester les détails d'implémentation n'a pas de sens.

[gl]

Pourquoi est-ce qu'une classe de test aurait besoin de connaitre l'invariant d'une autre classe ? Le test est là pour tester la validité des pré-conditions / post-conditions, ainsi que la validité du résultat.

Peut-être pour tester que justement l'invariant de classe est bien respecté au sein de la classe. Non ?
Cela ne me semble pas totalement illogique que les tests unitaires valides également les invariants..

[gbdivers]

Peut-être pour tester que justement l'invariant de classe est bien respecté au sein de la classe. Non ?
Cela ne me semble pas totalement illogique que les tests unitaires valides également les invariants.

Si l'invariant est public, ça aurait un sens de le tester (par exemple un numéro d'identification qui serait attribué automatiquement et que l'on pourrait lire mais pas modifier)
Ici, c'est un invariant que l'on ne peut ni lire, ni modifier (donc un détail d'implémentation, servant en interne). Il faut plutôt tester que les fonctions qui utilisent cet invariant respectent bien leurs contrats, peux importe la gestion interne, non ?

[gl]

Ici, c'est un invariant que l'on ne peut ni lire, ni modifier (donc un détail d'implémentation, servant en interne). Il faut plutôt tester que les fonctions qui utilisent cet invariant respectent bien leurs contrats, peux importe la gestion interne, non ?

De mon point de vue, lors du test unitaire de fonctions membres de la classe (ou de fonctions non-membres amies de cette classe), tester que l'invariant est toujours vérifié après l'appel de la fonction me semble être plutôt une bonne idée.
Maintenant, un invariant de classe qui n'est pas visible publiquement (directement ou indirectement via d'autres éléments) ça ne court pas non plus les rues. Assez fréquemment, la validation des post-conditions permet de valider également les invariants de classes.

[Emmanuel Deloget]

Peut-être pour tester que justement l'invariant de classe est bien respecté au sein de la classe. Non ?
Cela ne me semble pas totalement illogique que les tests unitaires valides également les invariants..

L'invariant de la classe est supposé être respecté à partir du moment ou là classe effectue le travail qu'elle doit faire. Le cas ou la classe fonctionne exactement comme prévu mais que l'invariant de la classe peut être dans un stade où il n'est plus valide est impossible (démonstration par l'absurde : si une classe avec des données intrinsèque respecte en permanence sont contrat mais que son invariant est invalide, ça veut dire que les données intrinsèques sont à la fois valides et invalides),

L'invariant est réellement un détail d'implémentation. Tester l'invariant signifie que l'on doit connaitre de détails d'implémentation. Un changement peut alors provoquer la nécessiter de réécrire les tests, sans pour autant que la valeur des tests ne changent - puisque ce qu'on leur demande en principal, c'est de vérifier les fonctionnalités offertes par une classe.

[gl]

L'invariant de la classe est supposé être respecté à partir du moment ou là classe effectue le travail qu'elle doit faire. Le cas ou la classe fonctionne exactement comme prévu mais que l'invariant de la classe peut être dans un stade où il n'est plus valide est impossible (démonstration par l'absurde : si une classe avec des données intrinsèque respecte en permanence sont contrat mais que son invariant est invalide, ça veut dire que les données intrinsèques sont à la fois valides et invalides),

L'invariant est réellement un détail d'implémentation. Tester l'invariant signifie que l'on doit connaitre de détails d'implémentation. Un changement peut alors provoquer la nécessiter de réécrire les tests, sans pour autant que la valeur des tests ne changent - puisque ce qu'on leur demande en principal, c'est de vérifier les fonctionnalités offertes par une classe.

OK, je comprends. Globalement je suis d'accord avec toi.

De mon point de vue, ici tu testes bel et bien le respect de l'invariant. Si ce n'est que tu ne vas pas le faire en inspectant "l'intérieur" de la classe mais en inspectant ses conséquences sur l'état publique de la classe.

En fait, je pense que j'ai mal compris ta première intervention. Visiblement tu parlais de l'invariant en terme d'implémentation. Alors que lorsque je parle d'invariant de classe, je parle d'un point de vue de la logique de la classe.

[Invité]

Merci pour les réponses déjà
Par contre, je vous suis pas trop...je reprends.

Pourquoi est-ce qu'une classe de test aurait besoin de connaitre l'invariant d'une autre classe

Ici, mon but, c'est de tester que la factory me retourne bien un neurone correspondant aux paramètres passés à la méthode appelée.
Je récupère en sortie un neurone. Son "identifiant" sont les parametres passés au constructeur. Je sais qu'ils sont bien settés (test sur le constructeur). Je veux m'assurer que la factory crée correctement mon neurone en testant son identifiant. Donc je teste pa l'invariant de mon neurone "en soi", je récupère sa valeur pour affirmer que la factory me retourne bien le bon neurone!

Ma classe de test est juste une solution (inspirée php et phpunit) ou l'on dérive une classe pour pouvoir accéder aux attributs privés/protected et surcharger les méthodes etc.

La classe doit être designée de manière à toujours dissimuler son invariant, et la classe de test a pour but de tester une interface

Je ne vois pas ce que tu entends par classe de test.
Pour moi une classe de test, c'est juste une classe qui fournit des methodes style Test::is(obj->doSomething(), resultatAttendu);
Pe veux tu dire par la que l'ensemble des tests réalisés sur une classe sont faits par une classe de tests?

Visiblement tu parlais de l'invariant en terme d'implémentation. Alors que lorsque je parle d'invariant de classe,

Ici, c'est ce qui m'empêche de profiter de vos posts, je ne comprends pas ce qu'on entend par invariant.
Qu'est-ce qu'un invariant en terme d'implémentation?
Qu'est-ce qu'un invariant de classe?
d'apres wiki, un invariant de classe peut être une condition implicite sur un entier. Ex : 1<entier<10.
A partir de là, ca me parait normal de tester que si en entrée d'une fonction j'ai un param correct, que l'entier est bien modifié avec des valeurs correctes? OK, l'utilisateur il s'en tape un peu de comment ca se passe dans la classe, mais par exemple si derrière jutilise une autre méthode qui s'appuie justement sur un attribut qui est des lors invalide, ben la fonction elle même fait bien son stuff, mais le résultat final est incohérent!

Bref, quelqu'un pour reprendre mollo avec moi?

J'avais aussi envie de revenir sur la démo par l'absurde, mais déjà si on peut déblayer cette notion d'invariant...

Pour revenir au problème initial. Si j'ai un setter, j'ai quand même envie de tester que la valeur que je sette est correctement settée. Non? Ou c'est justement ce quil ne faut pas faire ?