Rédaction de tests de haute qualité

Malheureusement, les tests ne reçoivent toujours pas l'attention qu'ils mériteraient dans de nombreuses organisations. Parfois, on a l'impression que les développeurs se sentent coupables s'ils n'écrivent aucun test, et en même temps, le code des tests n'est souvent pas correctement révisé. Au lieu de cela, la seule chose qui est souvent vérifiée dans une évaluation est s'il y a des tests, ce qui est dommage, car se contenter de tests ne suffit pas. En fait, ils devraient être au moins de la même qualité que tous les autres codes d’un projet, voire même de meilleure qualité. Sinon, les tests pourraient en effet vous freiner, car les tests échouent trop souvent, sont difficiles à comprendre ou prennent beaucoup trop de temps à s'exécuter. J'ai déjà abordé certains de ces points dans mon article de blog sur l'utilisation d'implémentations en mémoire au lieu de simulations de référentiel. Maintenant, je veux discuter d'autres choses, plus générales, auxquelles je fais attention lors de la rédaction de tests.

Le minimalisme est la clé

Stack Overflow vous demande d'ajouter des exemples minimaux et reproductibles aux questions, et à mon avis c'est aussi un très bon conseil pour rédiger des tests pour exactement les mêmes raisons. Surtout lorsque vous lisez un test des mois après l'avoir rédigé, il est beaucoup plus facile de comprendre pleinement ce qui se passe s'il se passe moins de choses. Alors écrivez uniquement le code qui est absolument nécessaire pour le test, et résistez à la tentation d'ajouter plus de choses simplement parce que c'est facile de le faire. Mais le code du test doit bien entendu rester complet, c'est-à-dire qu'un test doit contenir autant de lignes que nécessaire, mais le moins possible.

Optez pour la couverture de code à 100 %

C'est peut-être une opinion impopulaire, mais je pense qu'il est tout à fait logique de viser une couverture de code à 100 %, même si beaucoup semblent considérer cela comme une mauvaise pratique.

Parfois, les équipes se contentent d'une valeur inférieure, par ex. une couverture de code de 90%. Cependant, cela n’a pas beaucoup de sens pour moi. Tout d’abord, tous ces chiffres sont quelque peu arbitraires et difficiles à étayer à l’aide de données. De plus, lors de l’écriture d’un nouveau code, il n’est pas nécessaire de le tester entièrement pour dépasser ce seuil. Et si quelqu'un parvenait à augmenter la couverture, la personne suivante pourrait s'en sortir sans écrire de tests tout en conservant une couverture de code supérieure à 90 %, ce qui entraînerait un faux sentiment de confiance.

L'une des excuses que j'entends souvent est que cela n'a pas de sens d'écrire des tests pour des fonctions simples comme les getters et les setters. Et peut-être étonnamment, je suis totalement d’accord avec cela. Mais voici le problème : Si aucun des tests n'utilise réellement ces getters et setters, alors il n'est probablement pas nécessaire de les avoir. Ainsi, au lieu de se plaindre de la difficulté d'obtenir une couverture de test à 100 %, il serait probablement préférable de ne pas écrire de code qui n'est pas requis en premier lieu. Cela évite également le fardeau de maintenance que chaque ligne de code entraîne.

Cependant, il y a un petit problème : parfois le code fait des choses étranges, ce qui peut amener les outils de couverture de code à marquer certaines lignes comme non couvertes, même si elles ont été exécutées pendant l'exécution du test. Je n'ai pas souvent rencontré de situations comme celle-ci, mais s'il n'y a aucun moyen de faire fonctionner cela, je les exclus de la couverture du code. Par ex. PHPUnit permet de le faire en utilisant son annotation codeCoverageIgnore :

<?php class SomeClass
{
    /**
     * @codeCoverageIgnore
     */
    public function doSomethingNotDetectedAsCovered()
    {

    }
}

De cette façon, cette fonction n'est pas incluse dans l'analyse de couverture de code, ce qui signifie qu'il est toujours possible d'atteindre une couverture de code de 100%, et je continue également de vérifier cette valeur. L'alternative est de se contenter d'une valeur inférieure à 100 %, mais on retrouve alors les mêmes problèmes mentionnés ci-dessus : d'autres codes peuvent également ne pas être couverts par les tests, et cela peut être manqué.

Cela étant dit, une couverture de code à 100 % ne donne certainement aucune garantie que votre code ne contient aucun bug. Mais si vous avez des lignes non couvertes dans votre code d'application, vous n'apportez même pas de modification à vos tests pour détecter les erreurs potentielles dans cette ligne.

Écrivez de bonnes affirmations

La raison pour laquelle des tests sont écrits est que nous voulons affirmer un certain comportement du code. Les assertions sont donc une partie essentielle des tests.

Bien sûr, la considération la plus importante lors de l'écriture d'assertions est qu'elle teste correctement le comportement du code. Mais la façon dont l’assertion se comporte lorsque le code échoue est en deuxième position. Si une assertion échoue pour une raison quelconque, le problème doit être aussi évident que possible pour le développeur. Une situation dans laquelle cela est évident est la situation sur laquelle on travaille actuellement dans cette pull request Symfony. Symfony est livré avec une méthode assertResponseStatusCodeSame, qui permet de vérifier le code d'état d'une réponse dans un test fonctionnel :

<?php declare(strict_types=1);

class LoginControllerTest extends WebTestCase
{
    public function testFormAttributes(): void
    {
        $client = static::createClient();

        $client->request('GET', '/login');
        $this->assertResponseStatusCodeSame(200);

        $this->assertSelectorCount(1, 'input[name="email"][required]');
    }
}

Le problème avec ce test est la sortie qu'il génère au cas où le code d'état n'est pas 200. Étant donné que les tests sont généralement exécutés dans un environnement de développement, Symfony renverra une page d'erreur lors de l'accès à cette URL, et la méthode assertResponseStatusCodeSame affichera le réponse complète en cas d'échec de l'assertion. Cette sortie est incroyablement longue, car elle renvoie non seulement du HTML, mais également du CSS et du JavaScript, et mon tampon de défilement est littéralement trop petit pour me permettre de lire l'intégralité du message.

C'est absolument le pire exemple que j'ai rencontré jusqu'à présent, mais cela peut aussi être ennuyeux si de mauvaises assertions sont utilisées dans le code. Jetons un coup d'œil au résultat de l'assertion assertSelectorCount ci-dessus, qui échoue avec le message suivant si le sélecteur donné ne produit pas exactement un élément :

Failed asserting that the Crawler selector "input[name="email"][required]" was expected to be found 1 time(s) but was found 0 time(s).

Cela donne une assez bonne idée du problème qui se produit. Cependant, l'assertion pourrait aussi s'écrire d'une manière différente (ne faites pas ça chez vous !) :

<?php class SomeClass
{
    /**
     * @codeCoverageIgnore
     */
    public function doSomethingNotDetectedAsCovered()
    {

    }
}

Quelqu’un pourrait dire que cela fait exactement la même chose, donc peu importe la variante utilisée. Cela ne pourrait pas être plus éloigné de la vérité, puisque le message suivant apparaît s'il n'y a pas un seul champ de saisie obligatoire pour un e-mail :

<?php declare(strict_types=1);

class LoginControllerTest extends WebTestCase
{
    public function testFormAttributes(): void
    {
        $client = static::createClient();

        $client->request('GET', '/login');
        $this->assertResponseStatusCodeSame(200);

        $this->assertSelectorCount(1, 'input[name="email"][required]');
    }
}

Cela n'aide pas du tout, et quiconque travaille à résoudre le problème doit d'abord comprendre quel est réellement le problème. Ce que cela montre, c'est qu'une assertion appropriée doit toujours être utilisée, et PHPUnit est livré avec de nombreuses assertions adaptées à tous types de cas d'utilisation. Parfois, il est même judicieux de créer une assertion personnalisée.

Une assertion relativement nouvelle que j'ai vue gagner en popularité ces dernières années est celle des tests instantanés. Surtout lorsque l'on commence à travailler sur un projet front-end, cela semble beaucoup aider. Je l'ai souvent utilisé avec React dans le passé. L'essentiel est que vos tests ressemblent à ceci :

Failed asserting that the Crawler selector "input[name="email"][required]" was expected to be found 1 time(s) but was found 0 time(s).

La magie opère dans la méthode toMatchSnapshot. Lors de la toute première exécution, il écrit le contenu de la variable arborescente dans un fichier séparé. Lors des exécutions suivantes, il compare la nouvelle valeur de l'arborescence avec ce qu'elle a précédemment stocké dans son fichier séparé. Si quelque chose change, le test échouera et affichera une différence, avec une option permettant de mettre à jour à nouveau l'instantané, ce qui signifie que vous pourrez corriger vos tests en un clin d'œil.

Bien que cela semble vraiment sympa, cela comporte également quelques inconvénients. Premièrement, les instantanés sont assez fragiles, car chaque fois que le balisage rendu du composant change, les tests échouent. Deuxièmement, l’intention du test est cachée, puisqu’elle n’explique pas ce que l’auteur voulait réellement tester.

Cependant, ce que j'ai vraiment apprécié, c'est que chaque fois que je modifiais un composant, cela me rappelait tous les autres composants utilisant ce composant, car tous ces instantanés échouaient lors de l'exécution suivante. Pour cette raison, j'ai aimé avoir au moins un test instantané par composant.

Conclusion

Donc, pour résumer, je pense qu'il y a quelques choses que vous pourriez commencer à faire dès maintenant afin d'améliorer la qualité de vos tests :

• Conservez le code dans un test au minimum absolument requis
• Visez une couverture de code de 100 % et excluez correctement le code du mécanisme de couverture de code s'il ne peut pas être testé
• Utilisez les assertions correctes pour obtenir de meilleurs messages d'erreur lorsque vos tests échouent

À mon avis, suivre ces quelques règles fera déjà une énorme différence et vous aidera à profiter longtemps de travailler dans la base de code !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!