Vos tests automatisés vous protègent-ils réellement ?

Vous ne pouvez pas garantir un code sans bug. Mais vous pouvez valider votre suite de tests pour vous assurer que vous détectez autant de bugs que possible.

Soyons clairs : les tests sont probablement le moyen le plus inefficace d’éliminer les bugs imaginables… mais c’est ce que nous avons actuellement. Et même si je suis évidemment un grand fan de tests automatisésles tests automatisés ne sont pas une panacée. Mais en disant aux gens de « bien écrire, SOLIDE code » n’est pas une protection suffisante car (comme nous le savons tous) même le code écrit avec les meilleures intentions comporte des bugs.

Mais pourquoi les tests automatisés ne sont-ils pas la solution finale ? Parce qu’après tout, votre suite de tests se compose de deux choses : des entrées et… (attendez)… du code. Ce code de test, comme tout autre code, est sujet à des bugs. Et lorsque vous avez un bug dans votre suite de tests, vos tests ne peuvent en fait pas vous protéger contre l’implémentation de bugs dans votre système de production.

Tout cela signifie simplement que vous devez rechercher les bogues dans vos tests automatisés avec autant de diligence que vos tests automatisés recherchent les bogues dans le code de votre application. Cependant, vous ne voulez pas tester votre code de test en écrivant davantage de code. Si vous faites cela, vous allez entrer dans une régression infinie de l’écriture de code qui vérifie le code qui vérifie le code qui… Vous avez besoin de différents mécanismes pour valider votre code de test. tests automatisés.

Comment les tests automatisés échouent

Pour comprendre comment vous pouvez valider votre code de test, vous devez considérer les trois façons dont vos tests automatisés peuvent échouer :

1. Le faux négatif: Un test échoue lorsqu’il n’y a rien de mal car le test (code ou entrées) est mal écrit. Mais ce n’est pas vraiment un problème. Premièrement : tant que votre test échoue, votre code ne passera pas en production, là où vos bogues sont importants. Deuxièmement : vous allez enquêter sur tout test ayant échoué et résoudre le problème. C’est dommage pour les retards ou les coûts associés à la correction du test, mais aucun bug ne sera déployé en production : le faux négatif est un problème auto-correctif.

2. Le test manquant: Vous n’avez pas reconnu un point d’échec potentiel, vous n’avez pas écrit de test pour le vérifier et (par conséquent) vous n’avez pas détecté l’inévitable bug qu’un test aurait détecté. Soit dit en passant, c’est la conséquence de la Cinquième Loi dans mon esprit. 10 lois immuables des tests: Tout ce que vous ne testez pas contient un bug.

3. Le faux positif: Un test qui rapporte un succès alors qu’en fait, quelque chose ne va pas. Considérez-les comme des « tests minables » et ils se déclinent en deux variétés :

   » Un test qui ne prouve pas ce que vous pensez qu’il prouve. Par exemple, vous essayez de prouver que quelque chose le ou avant la date d’expédition sera rejetée mais le test vérifie uniquement les dates avant la date d’expédition.

   » Une épreuve qui ne peut jamais échouer. Mea culpa : j’ai écrit l’un de ces tests : je vérifiais une routine de tri et j’utilisais des données de test déjà triées. Même si ma routine de tri ne faisait rien du tout, mon test allait réussir (et, comme nous l’avons découvert en production, mon code de tri ne faisait rien du tout).

Étant donné que ce sont tous des bugs que vos tests automatisés peuvent avoir, comment vous assurer qu’il n’y a pas de tests manquants ou minables ?

Gérer les tests manquants

Pour le test manquant, vous devez considérer toutes les raisons possibles pour que votre code puisse mal tourner et fournir un test pour vérifier chacune de ces manières. C’est un conseil stupide car, bien sûr, vous avez l’impression de le faire déjà.

Mais je parie que vous créez une liste d’intrants que vous considérez comme « dangereux ». Ce n’est pas la même chose que de créer des entrées avec toutes les valeurs possibles (valides et non valides) et toutes les combinaisons possibles de ces valeurs. Il pourrait être intéressant d’envisager un outil de génération de données de test qui sera plus objectif que vous dans la génération de toutes les entrées potentielles pour votre application.

Mais, en plus de vos contributions, vous devez prendre en compte toutes les différentes façons dont votre application peut être utilisée. Vous n’êtes pas aussi bon dans ce domaine que vous le pensez, car vous examinez l’application du point de vue d’un développeur ou d’un ingénieur de test. Au lieu de cela, commencez à faire appel à des utilisateurs finaux (qui ont un point de vue très différent du vôtre) et demandez-leur de mettre l’accent sur votre application. Ils généreront de multiples tests auxquels, je vous le garantis, vous n’aurez pas pensé.

Et même si je ne suis pas un grand fan des statistiques de couverture, elles peuvent être utiles ici. Permettez-moi d’être clair sur les statistiques de couverture : mon sentiment est que si vous avez réussi tous vos tests, alors vous avez réussi tous vos tests : votre application est aussi exempte de bogues que possible, quel que soit le code utilisé. ou n’est pas exécuté. Mais mon affirmation suppose que vous avez « tous les tests ».

Ainsi, si votre rapport de couverture montre que vous avez du code qui n’est pas exécuté, vous devez alors déterminer s’il s’agit d’un code auquel on ne peut jamais accéder (« code mort ») ou d’un code qui n’est pas exécuté parce qu’il vous manque un code. cas de test. En fonction de ce que vous déterminez, vous devez alors agir :

• S’il ne s’agit pas de code mort, vous devez écrire un test pour exécuter ce code et voir s’il fonctionne.
• Si c’est du code mort, vous devez le supprimer.

Si la suppression de code vous inquiète parce que, après tout, le changement est notre ennemi, je vais simplement citer (encore une fois) ma cinquième loi des tests : tout ce que vous ne testez pas contient un bug. Cela étant vrai, puisque le « code mort » est un code que vous ne testez pas, vous laissez alors du code bogué dans votre application. CQD

Tests minables

Pour trouver les tests qui ne font pas ce que vous pensez qu’ils font, vous avez besoin d’un ensemble spécial d’entrées qui garantiront que chacun de vos tests échouera… et qu’il échouera de toutes les manières possibles. Considérez cela comme votre « suite de tests d’échec garanti ».

Si vous exécutez un test avec ces entrées et que certains tests n’échouent pas, alors vous avez trouvé un test minable. Une fois que vous avez trouvé ces tests, vous devez encore une fois agir :

• Corrigez ces tests afin qu’ils signalent réellement les bogues dans votre « suite de tests d’échec garanti ».
• Supprimez ces tests car ils ne font évidemment rien d’utile et ne font qu’ajouter à la charge de maintenance de votre suite de tests.

Si vous ne pouvez pas générer un test qui entraînera l’échec d’un code (par exemple, le test doit imiter que l’application est simultanément hors ligne et continue, d’une manière ou d’une autre, à accepter les entrées), alors vous avez vraiment une condition qui ne peut jamais se produire. Il vous suffira d’espérer que les conditions qui entraîneront l’exécution de ce code ne pourront pas se produire en production. Mais cela dit, je m’assurerais de ne pas trouver de moyen ingénieux de créer un test pertinent.

Et c’est toujours une bonne idée de demander à une autre personne de vérifier vos tests pour s’assurer que vos tests font ce que vous pensez qu’ils font. Pour cela, vous devrez documenter ce que chaque test est censé prouver (l’intention du test) afin que « l’autre personne » puisse évaluer le test par rapport à l’intention du test.

Vous pouvez documenter l’intention du test avec un commentaire, mais une meilleure solution consiste à écrire le code pour indiquer l’intention de votre test (en appelant le test « ShippingDateIsOnOrBeforeOrderDate », par exemple, plutôt que « ShippingDateBad »). L’ajout d’un commentaire devrait être votre deuxième choix.

C’est également une bonne idée de garder vos tests aussi simples que possible. Limitez la phase d’action de vos tests à une ou deux lignes, écrites de la manière la plus claire possible afin que, si le test est minable, il soit immédiatement évident pour quiconque le lit. Cela vous permettra d’avoir beaucoup de tests simples, mais je pense que c’est préférable à quelques tests volumineux et complexes.

Mais ce dernier conseil n’est pas nouveau pour vous : c’est après tout l’un des capacités d’adaptation nous avons adopté pour réduire les bogues dans n’importe quel code.

Le meilleur conseil

Puisque nous avons bouclé la boucle et sommes revenus à « écrire du bon code », voici un dernier conseil « lié à la suite de tests » : si, lors de l’audit de votre suite de tests, vous trouvez un bug, chercher plus. Si vous étiez dans une chambre d’hôtel et voyiez un cafard, vous ne diriez pas : « Oh, regarde, il y a un cafard. » Non : vous diriez : « Oh mon Dieu, cet endroit est infesté. » Comme les bogues du monde réel, les bogues dans le code, y compris le code de test, se déplacent généralement en packs : lorsque vous voyez un bogue, recherchez-en d’autres.

Ces outils et techniques garantiront-ils qu’aucun bug n’entrera en production ? Non (et ne soyez pas stupide). Mais cela vous aidera à valider votre suite de tests (code et entrées) afin que lorsqu’un bug entre en production, vous n’ayez pas l’air stupide.