Discussion :

[Pierre Fauconnier]

Salut.

Je me pose une question existentielle, qui n'est pas spécifique java, mais comme c'était à un cours de java, je la poste ici.

Lors d'un test unitaire sous JUnit lancé plusieurs fois d'affilée, le test valide parfois la fonction, parfois non... Evidemment, la fonction testée contient une ligne de code qui peut effectivement poser problème.

Le "prof" (il paraît que c'est comme cela qu'on doit l'appeler) qui "donne cours" de java soutient mordicus que le code de test qu'il a donné est correct et qu'un test unitaire ne saurait pas "tout tester"... Et donc que c'est normal que le test ne renvoie pas toujours la même valeur lors de plusieurs run successifs. Je soutiens le contraire et je soutiens qu'il faut améliorer le test. A quoi servirait un test sur lequel on ne pourrait pas se fier?

Et vous? Votre avis? (Je jure, au passage, que ce n'est pas un troll, c'est vraiment un "prof" qui a soutenu cela lors d'un cours en bachelier informatique de gestion, et comme il soutient aussi qu'il ne faut pas faire d'héritage mais de l'interface "parce que c'est plus souple", je me pose des questions sur ses compétences réelles)

[adiGuba]

Salut,


La question est : quel est la fonction et le test correspondant, et surtout pourquoi des fois "çà ne marche pas ?"


a++

[tchize_]

Typiquement le genre de test content des choses asynchrone ou une partie de hasard. De là, je vois trois possibilité


Possibiltié 1: le test réussi parfois car il ne capte pas toujours l'erreur. Exemple: 2 threads font un travail en parallèle et parfois ( une fois sur dix par exemple) , concurrence oblige, le résultat c'est de la m***. Ce cas d'erreur doit être analysé car il peut se poser aussi dans l'application en prod, il doit être rendu reproductible autant que possible (par exemple en forcant des synchros ou du délai dans les threads concernés via des mockups, en multi thread c'est vite galère) et être spécifiquement testé. Dans le vraiment pire des cas, on sait que ça se produit une fois sur 10 donc on règle le test pour tourner 100 fois en boucle, mais franchement c'est quand tu trouve pas de solution pour faire mieux et il vaux mieux sortir la feuille à calcul pour trouver le problème que sortir ce lance flamme et espérer que ça brule tout.

Possibilité 2: le test foire de temps en temps alors qu'il ne devrait pas, tout se comporte correctement. Le problème est dans le test pas dans le code testé. Ne pas laisser le test merder une fois sur 10 pour rien et inquiéter tout le monde, ou pire avoir tout le monde qui ignore les erreurs du test parce que "on a l'habitude". Corriger le test pour que ces erreurs ne se produisent plus

Possibilité 3: Il n'y a pas vraiment d'erreur, mais des effets de l'environnement de test incontrôlables. Exemple que j'ai: on teste un truc asynchrone avec des queue jms. Le test fonctionne comme ceci: poster dans la queue, attendre que le backend aie effectué l'op"ration, vérifier le résultat. Si tu attends indéfiniment, le jour ou le backend ne prendra pas, tu n'aura pas d'erreur, juste une jvm qui traine depuis des heures. Si tu attends, disons 4 secondes et que ton serveur de build est bien chargé, tu pourrais avoir des faux négatifs qui disparaissent au rerun. Si tu attends disons 2 minutes pour être sûr et que la totalité des 600 tests foirent, faudra attendre 20 heures pour avoir un résultat Là les pistes d'amélioration c'est d'essayer de détecter les erreurs courantes avant la fin de l'attente, jouer sur la charge du serveur de test, trouver le temps d'attente qui supprime les fausses alertes sans rendres les tests inutilisables au quotidien.


Dans tous les cas, un test c'est vert ou rouge, il n'y a pas d'intémédiaire: vert tout est ok, rouge il y a un problème qui doit être corrigé. Si tu t'embarque sur du "rouge on laisse faire", alors tes tests seront ignorés. Si tu t'embarque sur du "vert mais on va relancer pour être vraiment sûr" alors tes tests ne sont pas fiables et il faudra relancer combien de fois? Un test peux foirer une fois sur mille mais en prod ce 1/1000 peux vouloir dire un bug toutes les 2 heures....

[Gugelhupf]

Un test unitaire doit être idempotent, si ce dernier retourne un coup du vert puis un coup du rouge, c'est que le test unitaire n'est pas bon.

Un test unitaire qui contient une connexion réseau (donc le fait d'établir une connexion hors du localhost) n'est jamais fiable car notre test devient dépendant d'une entité sur laquelle on n'a pas toujours la main. Penser à mocker toutes les dépendances (librairie faisant parti d'un autre projet) est déjà un bon début.

Pierre Fauconnier, peux-tu nous montrer ce test unitaire ?

PS : _tchize, je n'ai pas encore vu de cas où on utilise Random dans un test unitaire, je teste avec des valeurs constantes, mais si on fait intervenir du Random il faut prévoir la bonne plage de valeur [a, b] (mais est-ce que cela en vaut la peine je ne pense pas).

[tchize_]

PS : _tchize, je n'ai pas encore vu de cas où on utilise Random dans un test unitaire, je teste avec des valeurs constantes, mais si on fait intervenir du Random il faut prévoir la bonne plage de valeur [a, b] (mais est-ce que cela en vaut la peine je ne pense pas).

Je pensais plutôt à la fonction testée qui fait intervenir Random


Mais même là, on peux initialiser Random avec une ou plusieurs seed histoire que la pseudo liste aléatoire soit la même à chaque run.

[Pierre Fauconnier]

Merci déjà à vous pour vos éclairages.

Je rappelle bien que la discussion est ici générale et ne porte pas sur une fonction particulière ou un test particulier. Elle fait suite au fait que j'ai été interpellé par la déclaration d'un "prof" de java qui disait qu'un test unitaire peut parfois retourner du vert et parfois du rouge, ne comprenant apparemment absolument pas que le test est alors non fiable et qu'on peut arrêter de perdre son temps à faire des tests unitaires. Réponse du prof: Ca dépend du point de vue, et un test unitaire ne pourra de toute façon tout tester (in peto, je me dis que ce n'est pas une raison pour ne pas corriger le test s'il affiche des faiblesses manifestes). Je précise que cette "joute" inamicale est à placer dans le contexte d'un cours durant lequel ce "prof" insiste sur l'importance des tests unitaires. Et la réponse qu'il m'a faite "c'est ton point de vue (de dire qu'un test doit toujours renvoyer ou vert ou rouge et pas parfois l'un et parfois l'autre), mais ce n'est pas le mien. C'est juste une question d'avis et mon test est correct, il tourne depuis plusieurs années sans soucis" m'a évidemment laissé pantois et m'a fait me poser de sérieux doutes sur la qualité du prof (c'est faux, je savais déjà qu'il était nul).

Un test unitaire doit être idempotent, si ce dernier retourne un coup du vert puis un coup du rouge, c'est que le test unitaire n'est pas bon.[...]

C'est bien ce que je pensais du test unitaire et de son utilité.

[...]

PS : _tchize, je n'ai pas encore vu de cas où on utilise Random dans un test unitaire, je teste avec des valeurs constantes, mais si on fait intervenir du Random il faut prévoir la bonne plage de valeur [a, b] (mais est-ce que cela en vaut la peine je ne pense pas).

Dans le test incriminé, il y a un Random, et c'est justement ce qui m'a mis la puce à l'oreille sur la faiblesse éventuelle et finalement avérée du test unitaire.

[...]

Possibilité 2: le test foire de temps en temps alors qu'il ne devrait pas, tout se comporte correctement. Le problème est dans le test pas dans le code testé. Ne pas laisser le test merder une fois sur 10 pour rien et inquiéter tout le monde, ou pire avoir tout le monde qui ignore les erreurs du test parce que "on a l'habitude". Corriger le test pour que ces erreurs ne se produisent plus
[...]

Cela conforte mon opinion sur le fait que le test doit toujours renvoyer la même valeur. J'ai sucré les autres cas envisagés dont tu parles, absolument convaincu que ce "prof" est incapable de comprendre un traître mot des exemples que tu prends.

Je précise que dans le cas envisagé, la fonction et sont tests sont très très très très basiques.

[Gugelhupf]

Bah tu sais les escrocs y en a partout, surtout en informatique

[hwoarang]

Tout a deja été dit mais je vais quand meme apporter ma pierre à l'édifice.
Deja, il faut differencier 2 types de tests. Ceux ou on a la main (par exemple appel à une fonction qui traite des données et verification que le resultat est bien ce qu'on en attend d'apres les données fournies) et ceux ou on fait intervenir du matériel externe (par exemple connexion sur un serveur pour recuperer une page web qui peut echouer si la connexion ou le serveur sont HS).
Dans le 2e cas, on peut accepter qu'on ait des tests negatifs de temps en temps.
Dans le premier cas, non. Si il y en a, c'est soit le test qu'il faut changer soit le code testé (en fonction d'ou est l'erreur). Mais un echec n'est jamais normal.

Concernant l'utilisation de Random, ca ne me choque pas pour des tests repetitifs (une boucle pour tester plusieurs fois la meme fonction). Mais en général, on prefere utiliser la meme batterie de données pour s'assurer que le hasard ne laisse pas passer un faux positif. L'idéal étant de tester l'ensemble des possibilités.

Dans tous les cas, la regle, c'est qu'un test unitaire qui echoue doit etre analysé. Ca ne doit jamais etre "normal". Si l'echec est causé par une cause exterieure (panne d'un serveur, plantage d'une appli externe qui fourni les données, ...), il faut verifier les conditions du test et le relancer. Mais comme ca a été dit, en milieu professionel, laisser un test qui échoue revient à ne plus faire de test puisque la validation ne s'alarmera pas en cas de probleme. Ca peut meme etre nuire aux autres tests puisque ca incitera l'equipe de validation à ne pas considerer comme un probleme de voir d'autres tests echouer (si celui-la échoue "normalement", pourquoi ce serait anormal pour les autres ?).

[Pierre Fauconnier]

Bah tu sais les escrocs y en a partout, surtout en informatique

C'est vrai que quand je lis dans son cours qu'il ne faut pas faire d'héritage mais des interfaces "parce que c'est beaucoup plus souple", je me dis que les étudiants qui seront passés dans ses mains vont en baver au début de leur vie professionnelle...

[thelvin]

Euh, c'est un fait que programmer par interface est nettement plus souple que par extension de classe, et qu'il n'y a pas de logique particulière dans le fait de s'enfermer définitivement dans des classes quand on pouvait encore rester à un niveau plus abstrait.

... Par contre, c'est peut-être pas la première chose à enseigner -_-°.

[Pierre Fauconnier]

Pourrais-tu expliquer le "plus souple" et donner quelques exemples? Parce que personnellement, au delà de ce qui m'apparait comme du dogmatisme, j'ai beaucoup de difficultés à voir en quoi c'est "plus souple". Différent et complémentaire, ok, mais "plus souple", je ne vois pas. (déjà que la notion de "plus souple" est éminemment subjective)...

Pour moi, les deux concepts ne s'excluent pas mutuellement, mais plutôt se complètent. On fait de l'héritage lorsque l'on doit faire de l'héritage et on utilise les interfaces si l'on a besoin d'utiliser les interfaces.

Sauf à dire des bêtises, ce qui est toujours possible, l'héritage n'existe qu'en POO, ce qui me fait dire qu'il a ses raisons d'exister, et qu'il se différencie suffisamment de l'interface que pour les deux notions soient complémentaires et puissent d'ailleurs être utilisées conjointement au sein d'une classe.

De plus, de là à faire de l'interface "un des principes de la po" au détriment de l'héritage, je n'ai pas souvent lu ça ailleurs que dans ce "cours".

[hwoarang]

C'est vrai que quand je lis dans son cours qu'il ne faut pas faire d'héritage mais des interfaces "parce que c'est beaucoup plus souple", je me dis que les étudiants qui seront passés dans ses mains vont en baver au début de leur vie professionnelle...

Non, ca, c'est moins bizarre. En java en particulier, ou on ne peut heriter que d'une classe à la fois, il vaut mieux utiliser des interfaces plutot que des classes. Parce que si tu crées une classe qui hérite d'une autre dont elle n'a pas vraiment besoin ou bien que ne permet que de factoriser un peu de code, tu peux te retrouver coincer si tu as besoin d'heriter d'une autre classe pour un meme fonctionnement.

Bref, quand tu as le choix, il faut préférer hériter d'une interface plutot que d'une classe.

[thelvin]

Il y a aussi le fait que deux notions existent :

1: De quoi doivent être capables les objets de tel type ? La liste exhaustive des méthodes offertes, en gros le contrat partagé avec tout le monde, qui sera honoré par les objets de ce type.

2: Comment s'y prennent-ils pour faire ça ? (Et éventuellement en quoi ça consiste au juste, ce que font ces méthodes, comme dans le cas d'un Comparator.) L'implémentation de ces capacités.

Faire une distinction claire et nette des deux clarifie beaucoup comment le code s'organise. Or pour le 1 c'est des interfaces et pour le 2 des classes.

[hwoarang]

Pourrais-tu expliquer le "plus souple" et donner quelques exemples?

Deja, je pense que l'extrait que tu as posté est extrait d'un livre qui traite de POO et pas de java en particulier. A mon avis, tu confonds "interface" au sens informatique du terme (une API) et "interface" en java qui est une classe simplifiée (qui évite les problématiques de l'héritage multiple).

[Pierre Fauconnier]

Deja, je pense que l'extrait que tu as posté est extrait d'un livre qui traite de POO et pas de java en particulier. A mon avis, tu confonds "interface" au sens informatique du terme (une API) et "interface" en java qui est une classe simplifiée (qui évite les problématiques de l'héritage multiple).

L'extrait vient des notes de cours d'un prof (il y a bien une bibliographie reprenant quatre bouquins mais j'avoue ne pas les avoir lus).

Perso, je ne confonds rien du tout. Je connais les interfaces en java, en c# et en VBA (oui oui) et je suis d'accord avec ta définition de "classe simplifiée". Personnellement, j'utilise l'image de "coquille vide" et de "contrat" pour un interface. Je ne suis, a priori pas en phase avec le fait que l'interface est plus souple qu'une classe, le "plus souple" étant éminemment subjectif (Ca veut dire quoi, plus souple?). Je me dis simplement que les deux notions existent et qu'il me semble sain de les faire coexister et de les utiliser l'une et l'autre à bon escient.

Evidemment, si comme le dit hwoarang, il y peu, voire pas de factorisation de code, il vaut mieux utiliser les interfaces, mais en déduire "bref, quand tu as le choix, il vaut mieux utiliser les interfaces", c'est aller vite en besogne selon moi. Ca veut dire quoi "avoir le choix"? On peut toujours utiliser l'interface à la place d'une classe, je ne vois donc pas quand on aurait le choix ou pas, puisqu'il me semble qu'on l'a toujours. Dis-je une bêtise lorsque j'énonce que l'on peut toujours remplacer un héritage par une interface?

Bref, à part dire "il vaut mieux", je ne comprends toujours pas les raisons objectives qui favoriseraient l'interface plutôt que la classe, puisqu'il me semble que cela dépend évidemment de ce que l'on modélise.

Perso, je dirais "il vaut mieux" utiliser l'héritage lorsque c'est pertinent d'utiliser l'héritage et l'interface lorsque c'est plus pertinent d'utiliser l'interface.

Tout cela nous éloigne du sujet principal de la discussion qui parlait de tests unitaires, mais ce n'est pas grave, cela peut être instructif.

[Gugelhupf]

Pierre, voici une définition de mon professeur (doctorant) :

« Une interface décrit une capacité, ce qui se traduit par des méthodes à implémenter ».

Techniquement (et depuis Java 8) une interface n'est rien d'autre qu'une classe contenant des éléments public et surtout ne possédant pas d'attribut. Dans les faits, utiliser des interfaces est une manière détournée de faire de l'héritage multiple, en évitant les problèmes liées au Deadly Diamond of Death que tu peux rencontrer en C++ par exemple.

La question est maintenant de savoir dans quel cas implémenter une interface ou hériter d'une classe par exemple. On hérite d'une classe lorsque notre classe peut-être considérée comme une implémentation directe de cette dernière :

Code Java :

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
abstract class Boite {
    public abstract void ouvrir();
    public abstract void fermer();
}
 
class BoiteEnCarton extends Boite {
 
    @Override
    public void ouvrir(){
        // Implémentation
    }
 
    @Override
    public void fermer(){
        // Implémentation
    }
}

Jusque-là rien de bien méchant. Maintenant si nous avons d'autres types de boite (BoiteEnMetal, BoiteEnBois etc), il est fort probable que tes méthodes ouvrir() et fermer() vont se ressembler... on pourrait alors se dire : "Mais pourquoi on ne fourre pas tout dans Boite comme ça tout le monde en hérite !", sauf qu'on peut par exemple considérer que notre BoiteEnMetal se ferme de la même manière qu'une BoiteEnCarton, mais ne s'ouvre pas de la même manière. Et si cas inverse nous avons une BoiteEnBois qui s'ouvre mais qui ne se ferme pas de même manière comment fait-t-on ?

Nous pouvons donc créer 2 interfaces de "comportement" :

Code Java :

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

1
2
3
4
5
6
7
interface Ouvrable {
    void ouvrir();
}
 
interface Fermable {
    void fermer();
}

Et les différentes implémentations qui vont avec :

Code Java :

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

1
2
3
4
5
6
7
8
9
10
11
class OuvertureLaterale implements Ouvrable {
    @Override 
    public void ouvrir(){}
}
 
class OuvertureZip implements Ouvrable {
    @Override 
    public void ouvrir(){}
}
 
// Etc

Puis utiliser la composition pour éviter l'héritage multiple :

Code Java :

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
abstract class Boite {
    protected Ouvrable o;
    protected Fermable f;
 
    public Boite(Ouvrable o, Fermable f){
        this.o = o;
        this.f = f;
    }
 
    public void ouvrir() {
        o.ouvrir();
    }
 
    public void fermer() {
        f.fermer();
    }
}
 
class BoiteEnCarton extends Boite {
    public BoiteEnCarton(){
        // La magie c'est ici
        super(new OuvertureLaterale(), new FermetureLaterale());
    }
}

Pattern de comportement (ici le pattern Strategy), c'est ce qu'on appelle "plus souple" car on reste dans un cadre logique d'héritage tout en évitant la duplication de code : une BoiteEnMetal est une Boite, une BoiteEnMetal n'hérite pas de BoiteEnCarton juste parce que qu'une méthode fermeture est la même, une BoiteEnMetal n'est pas un comportement Ouvrable.

[hwoarang]

Tout cela nous éloigne du sujet principal de la discussion qui parlait de tests unitaires, mais ce n'est pas grave, cela peut être instructif.

A mon avis, pas vrament puisque la question est tranchée, non ?

Perso, je ne confonds rien du tout. Je connais les interfaces en java, en c# et en VBA (oui oui) et je suis d'accord avec ta définition de "classe simplifiée". Personnellement, j'utilise l'image de "coquille vide" et de "contrat" pour un interface.

Ok, j'avais cette impression de confusion qui se comprend puisque le meme terme est utilisé. Si ce n'est pas le cas, tant mieux.

Bref, à part dire "il vaut mieux", je ne comprends toujours pas les raisons objectives qui favoriseraient l'interface plutôt que la classe, puisqu'il me semble que cela dépend évidemment de ce que l'on modélise.

Ca, c'est évident. Mais dans un milieu professionel, avec un cahier des charges changeant, c'est pas évident en pratique. On ne peut pas toujours faire un cahier des charges de l'application dans sa globalité. Il est donc bon d'avoir des reflexes qui permettent de s'adapter plus facilement. Et l'interface s'adapte mieux que la classe.

Dis-je une bêtise lorsque j'énonce que l'on peut toujours remplacer un héritage par une interface?

Oui, c'est une bétise En pratique, tu vas souvent utiliser des frameworks qui t'imposent l'utilisation de classes ou interfaces. Et si, pour une raison ou une autre, tu as besoin d'étendre une classe d'un framework, bah t'as pas le choix, c'est une classe et pas une interface. Et si ca ne convient pas à ton application, parce que le framework n'est pas bien fait ou parce que tu ne l'utilises pas comme il est supposé l'etre, bah t'as pas le choix quand meme ^^

Bref, à part dire "il vaut mieux", je ne comprends toujours pas les raisons objectives qui favoriseraient l'interface plutôt que la classe, puisqu'il me semble que cela dépend évidemment de ce que l'on modélise.

Dans un milieu professionnel, il faut bien comprendre que le développement d'une application ne représente qu'une petite partie de la vie de celle-ci. La plus grosse partie est la maintenance. Faire une appli "from scratch", c'est rapide. La maintenir, une fois que l'architecture est créée, peut devenir un vrai casse tete si elle est mal faite. Dans cette optique la, il vaut mieux utiliser une interface lorsque c'est possible parce qu'une classe qui n'herite pas de l'interface A aujourd'hui (parce qu'elle n'en a pas besoin) peut avoir besoin d'en hériter demain. Et si tu as utilisé une classe parce que ca t'arrangeait mais que tu te retrouves avec le besoin de faire hériter une autre classe, bah en java, tu ne peux pas. Et la, ca peut vouloir dire remprendre des centaines/milliers de lignes de code.

[Pierre Fauconnier]

[...]
Oui, c'est une bétise En pratique, tu vas souvent utiliser des frameworks qui t'imposent l'utilisation de classes ou interfaces. Et si, pour une raison ou une autre, tu as besoin d'étendre une classe d'un framework, bah t'as pas le choix, c'est une classe et pas une interface. Et si ca ne convient pas à ton application, parce que le framework n'est pas bien fait ou parce que tu ne l'utilises pas comme il est supposé l'etre, bah t'as pas le choix quand meme ^^
[...]

C'est un aspect que j'ignorais. Merci

[...]
Faire une appli "from scratch", c'est rapide. La maintenir, une fois que l'architecture est créée, peut devenir un vrai casse tete si elle est mal faite. Dans cette optique la, il vaut mieux utiliser une interface lorsque c'est possible parce qu'une classe qui n'herite pas de l'interface A aujourd'hui (parce qu'elle n'en a pas besoin) peut avoir besoin d'en hériter demain. Et si tu as utilisé une classe parce que ca t'arrangeait mais que tu te retrouves avec le besoin de faire hériter une autre classe, bah en java, tu ne peux pas. Et la, ca peut vouloir dire remprendre des centaines/milliers de lignes de code.

Ca, c'est une argumentation que je peux déjà beaucoup plus facilement entendre

[professeur shadoko]

à propos des désaccord avec le "prof" un petit point.

Certes les enseignants ne sont pas infaillibles : il m'est arrivé de dire des bétises et certains "profs" sont carrément à coté de la plaque.
Toutefois mon conseil est de discuter: j'ai souvent vu des élèves qui avaient compris de travers (des choses qui n'étaient pas forcément clairement exposées)
et aussi des élèves qui soutiennent mordicus une position sur un point contre-intuitif: je me souviens d'un gars qui a hurlé quand j'ai expliqué qu'il était pratiquement impossible d'assurer un taux de 100% de couverture sur des tests. Il a vraiment dit des choses assez blessantes et il a fallu que je lui montre des exemples pour le calmer.

[tchize_]

je me souviens d'un gars qui a hurlé quand j'ai expliqué qu'il était pratiquement impossible d'assurer un taux de 100% de couverture sur des tests.

Mais si c'est possible