Discuter:JUnitX how to
Un article de Agile-Swiss.
Pas plus tard qu'il y a deux jours, j'ai justement fait un petit galop d'essai avec jUnitX en pensant à Jerry (private joke). J'étais justement dans ce genre d'impasse où une méthode est privée et que vous voulez la tester (à titre personnel je ne suis pas très convaincu par les théories selon lesquelles quand on se retrouve dans ce genre d'impasse c'est qu'on s'est perdu). Mis à part le fait qu'il a deux jours j'aurais bien aimé avoir ton article sous les yeux, je dois reconnaître que l'utilisation de jUnitX est tout de même assez verbeuse (de part la création du proxy pour un package, la manière d'invoquer les méthodes et de récupérer le résultat) mais puisqu'on l'utilise avec parcimonie pour tester les méthodes privées et qu'on a pas le choix c'est beaucoup, beaucoup mieux que rien.
Freddy
Verbeux ? Pas tant que ça ! Le petit hic c'est la classe Proxy dans le même package. Mais exclude dans vos jolies tâches ant, c'est pas pour les chiens ;-) Il y a effectivement des habitudes à prendre (savoir quels 'invoke' utiliser par exemple). Mais une fois qu'elles sont prises, on ne prend pas plus de temps à tester les méthodes privées que les méthodes publiques !
s t
Très intéressant cet article mais JUnitX est-il vraiment utile ? Je m'explique :
On veut tester son propre code, non pas celui de librairies externes... On a donc accès au code source. Alors pourquoi ne pourrait-on pas tout simplement redéfinir les méthodes private en protected ? Dans 99,9% des cas cela revient exactement au même et cela n'a aucun impact sur la qualité ou le comportement de l'appli (ou peut-être y a-il des cas particuliers que je ne vois pas ?).
Cela éviterait :
- de compliquer l'écriture des tests unitaires. JUnitX n'a quand même pas l'air d'être trivial ;-) ! Et il demandera de tout façon toujours plus d'effort que la modification private/protected !
- d'augmenter le niveau de dépendance de l'appli ("efferent coupling", estimable avec JDepend et son plug-in maven...).
Tout cela pour demander : le "Simple Design" XP ne passe-t-il pas aussi par le "Simple Testing" ?
Simon
Pas d'accord pour passer "ses" méthodes en protected au lieu de private, juste pour les tester. protected en plus d'être accessible dans le même package a une sémantique qu'il faut, je pense, respecter : cette méthode est destinée à la dérivation. Autre exemple, le code source issu d'un GUI builder peut générer des attributs private. Et tu n'as pas le droit de toucher à ces guarded blocks (merci NetBeans ;-(, ni le temps de fabriquer un accesseur purement technique.
Passons donc temporairement en protected puis en private pour la prod ? Non plus. Dans la pratique, on oublie de repasser les méthodes protected en private.
Je ne comprend pas ta remarque sur l'augmentation du niveau de dépendance ? Mais si tu accordes, et c'est vital sur le long terme, une grande importance au mantra "highly cohesive/loosely coupled", cela me semble contradictoire avec le fait d'ouvrir qquechose de private en protected.
OK avec le surcoût initial de mise en oeuvre. Si l'on ne veut tester qu'1 ou 2 méthodes privées, il n'y a pas d'intérêt à sortir l'artillerie JUnitX. Mais après 2 ou 3 tests privés effectués, c'est trivial ! (c.f réponse précédente)
"... non pas celui de librairies externes ... ". La question est ouverte, car théoriquement on devrait pouvoir tester les méthodes/attributs privés de librairies dont on ne dispose que des classes compilées. (merci javap si ma mémoire est bonne, oui je viens de vérifier, on peut choper les private via javap). Là je donne carrément le baton pour me faire battre avec cet exemple tiré par les cheveux ;-) et je vote aussi pour le Simple Testing.
JUnitX utile ? A vous de décider en fonction de votre projet. Dans notre cas, ce besoin s'est fait sentir, et son utilisation nous fait gagner du temps, sans sacrifier l'encapsulation.
s t
"Alors pourquoi ne pourrait-on pas tout simplement redéfinir les méthodes private en protected ? Dans 99,9% des cas cela revient exactement au même et cela n'a aucun impact sur la qualité ou le comportement de l'appli"
Ca a un impact sur ton encapsulation ;) ie sur ta manière de coder, une portion testée n'a pas à être modifiée (chgt de modifiers) parce que, justement, tu la testes. Le code n'est pas qu'une affaire de fonctions ;)
"JUnitX n'a quand même pas l'air d'être trivial ;-) ! Et il demandera de tout façon toujours plus d'effort que la modification private/protected !"
Le copier-coller est aussi plus facile que le refactoring et tout fonctionne aussi bien :p
Je suis bien triste si l'usage de JUnitX fait peur, il n'y a franchement pas de quoi, il existe des choses bien plus compliquées. Il faut l'essayer pour réaliser que son usage est rapide. Cette fausse complexité parait être une excuse pour ne pas avoir à se rassurer sur des petites portions de code, certains disaient la même chose il y a quelques temps à propos de JUnit :p. Si le code est correctement fractionné en petites méthodes de peu de lignes (cf. article de Didier), il risque d'y en avoir quelques unes (et je dis bien quelques unes, pas tout le code évidemment) pour lesquels on risque d'avoir des doutes sur le fonctionnement correct.
Bref... de toute manière, comme prévu, il y a matière à discussion ;)
J.
