mageekblog - Mesurer la testabilité à l'aide d'une métrique - CommentairesLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearMesurer la testabilité à l'aide d'une métrique - mageekguyurn:md5:dd30991bf8703818819d678a8d4f53a42009-04-15T13:22:02+02:002009-04-15T12:22:07+02:00mageekguy<p>@olivier:</p>
<p>Tester des méthodes protégées ou privées n'a strictement aucun sens, puisqu'elle ne sont pas publiques.</p>
<p>En effet, leur seule raison d'exister est d'être utilisée soit dans d'autre méthode privées ou protégées, soit dans des méthodes publiques pour participer à l'obtention du résultat de la méthode.</p>
<p>Elles sont donc de par leur nature même testées transitivement, via les tests sur les méthodes publiques.</p>
<p>Bref, vouloir tester des méthodes de ce type ne rime à rien, et par conséquent, il est inutile de chercher à bypasser le mécanisme d'encapsulation par l'utilisation d'accesseur ou de modificateur, même dans le cadre précis des tests.</p>
<p>L'encapsulation est un mécanisme qui a sa raison d'exister, ne serait ce que pour éviter la corruption des objets par le programmeur au cours de leur vie, ou bien justement pour le travail en équipe, puisqu'elle permet au programmeur de ne pas faire n'importe quoi.</p>
<p>L'encapsulation permet donc à un développeur qui ne connait pas le fonctionnement interne de l'objet (et il ne faut pas oublier que l'un des buts de POO est de masquer l'implémentation entre autre à l'aide de l'encapsulation) de l'utiliser sans compromettre son intégrité et éventuellement rendre instable le code dans son ensemble.</p>
<p>Et pour initialiser un contexte d'éxécution précis dans le cadre de tests sans accesseur/modificateur sur des membres privés ou protégés, il suffit de créer une instance de la classe à tester pour chaque contexte, en lui passant les arguments qui correspondent à ce contexte précis lors de sa construction.</p>
<p>C'est bien sur un peu plus verbeux, mais tellement plus propre !</p>Mesurer la testabilité à l'aide d'une métrique - Olivier Hoareauurn:md5:b90467b5a406345a82892ebee70996532009-04-15T10:15:23+02:002009-04-15T09:42:33+02:00Olivier Hoareau<p>Merci pour ces précisions qui poussent la réflexion un cran plus haut</p>
<p>En effet la formule est loin d'être parfaite car il s'agit d'un premier jet que j'étalonne actuellement sur du code en masse, comme toutes métriques elle a ses limitations, mais concrètement, elle fait ressortir les fichiers/classes sur lesquels il y a "quelque chose à dire". Finalement, ce n'est pas la valeur en elle même qui est importante mais l'appréciation, la différence relative avec les autres. Sur la dizaine de projet sur laquelle je l'ai expérimentée, elle m'a permis de mettre en exergue, quasi systématiquement les classes "dangereuses" (difficilement testable, compliquée...), et c'est ça le but de la manoeuvre surtout quand il y a des centaines de classes à vérifier...</p>
<p>L'injection de dépendances avec des méthodes/techniques magiques me semble dangereuse en contexte d'équipe car, maîtrisé par celui qui la développe, elle ne le sera pas forcément par les autres développeurs (i.e. "ce n'est pas standard"), où ceux qui arrivent après la bataille <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /></p>
<p>Je suis d'accord avec le fait que l'utilisation de méthodes publiques (setters/getters) n'est pas la plus adaptée pour certaines propriétés qu'il est souhaitable de garder en private/protected. Cependant toute variable de classe en private / protected est un "état" de l'objet (l'instance). 2 appels successifs à une méthode de l'objet peuvent donc se comporter différemment en fonction de l'état de l'objet. Le fait de positionner via un setter la valeur d'une variable de la classe et d'appeler directement une méthode de la classe permet de tester unitairement cette méthode dans un contexte "connu" (i.e. "je sais que la valeur de la variable est X " avant d'appeler la méthode Y).<br />
Sans les getters/setters le code peut être testable mais, à mon avis, pas toujours facilement testable "unitairement".</p>
<p>D'autre part, PHP est un langage assez permissif. Cela permet de faire de belles choses (des fois même de faire sa petite grenouille qui parle à soi...) mais cela permet de faire des choses compliquées / inmaintenables / inutiles aussi. La programmation objet pur et stricte telle que l'on nous l'apprend à l'école, personnellement je la trouve assez inadaptée à du code simple / maintenable / évolutif, bien sûr on peut faire des méthodes, propriétés et classes privées en POO, mais pour les tester unitairement après c'est une autre histoire (surtout quand on a une grappe d'objet encapsulés dans une variable d'une classe et que l'on ne peut pas instancier comme on veut ces objets via des setters). Je suis conscient de cette difficulté, et personnellement, j'ai fais le choix de développer plutôt "compatible" tests / maintenabilité / évolutivité et surtout, surtout "simplicité", même si je n'y arrive bien sûr pas toujours.</p>
<p>En tout cas merci pour ces précisions.</p>
<p>Je pense que nous aurons l'occasion de discuter d'autres "formules" bientôt... <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /></p>