Les tests d’OTP sont la petite partie tenace d’une suite de bout en bout qui lit un code à usage unique dans une boîte aux lettres et le ressaisit dans un formulaire. Cela semble trivial jusqu’à ce que ce soit peu fiable, et cela devient peu fiable pour des raisons qui n’ont rien à voir avec un code erroné : un message lent, un message plus ancien encore présent dans la boîte, un renvoi qui a été limité en débit. Cet article explique comment rendre cette étape fiable et quand arrêter de l’automatiser.
Ce dont une suite de bout en bout a besoin d’un message de code
Un message de code n’a qu’une tâche : transporter un court secret depuis votre application vers un endroit que le test peut lire. Tout le reste — mise en page, image de marque, pied de page, langue — est de la décoration du point de vue de la suite.
C’est cette asymétrie qui rend l’étape si facile à rater. Comme le test n’a besoin que de quelques caractères, il est tentant de les extraire au hasard, depuis le premier message qui semble assez proche. Le résultat est un test qui passe la plupart du temps et lit occasionnellement le mauvais message, ce qui est le type de test instable le plus coûteux : assez rare pour être écarté, assez réel pour masquer un vrai bug.
Quel est le bon message ?
L’identité, et non la seule récence. La règle la plus sûre est une combinaison : le message doit être adressé à l’adresse créée par ce cas, et il doit être le plus récent des messages correspondants dans cette boîte.
Les deux moitiés méritent leur place. La correspondance sur le destinataire élimine la contamination entre tests, car un message envoyé à l’adresse d’un autre cas ne peut satisfaire l’assertion, quelle que soit sa nouveauté. Préférer le plus récent parmi les correspondances gère le cas où le même parcours a été déclenché deux fois, une fois par une nouvelle tentative ou un essai antérieur.
La correspondance sur l’objet est une étape de resserrement utile quand une boîte contient légitimement plus d’un type de courrier — un message de bienvenue et un code, par exemple. Faites correspondre une partie stable de l’objet plutôt que la ligne entière, car les parties décoratives changent : le même objet avec une formule d’appel différente devrait encore correspondre.
Pourquoi les tests qui lisent des codes deviennent-ils instables ?
Quatre causes expliquent la majeure partie du phénomène, et chacune a une correction différente.
- Une attente fixe. Dormir un nombre constant de secondes est une supposition, et les suppositions sont soit trop courtes quand le message est lent, soit inutilement long quand il est rapide. Interrogez jusqu’à ce que le message apparaisse, avec un plafond qui fait échouer le test plutôt que suspendre l’exécution.
- Un message périmé. Si un cas réutilise une adresse, ou si une tentative précédente a laissé un message derrière elle, une recherche fraîche peut se satisfaire d’un ancien contenu. Donnez à chaque cas sa propre adresse ou, au minimum, notez ce qui était là avant le début du parcours et ignorez tout ce qui est plus ancien.
- Une limite de renvoi. Les parcours de code n’autorisent normalement que quelques renvois dans une courte fenêtre, ce qui est une protection délibérée plutôt qu’un défaut. Un test qui réessaie en demandant un autre code finira par être refusé et échouera pour la mauvaise raison ; réessayez en relisant la boîte plutôt qu’en appuyant sur le bouton.
- Une analyse trop empressée. Un corps peut légitimement contenir plusieurs nombres — une référence, un horodatage, un prix — et un analyseur qui saisit la première suite de chiffres en prendra parfois une mauvaise. Ancrez l’extraction sur le libellé autour du code plutôt que sur les seuls chiffres.
Quand faut-il qu’un humain reste dans la boucle ?
Certaines étapes ne devraient pas être automatisées, et prétendre le contraire produit des tests auxquels personne ne fait confiance.
Un humain est le bon outil quand le parcours nécessite un appareil qu’un pipeline n’a pas, quand le code arrive par un canal qui ne peut pas être lu par programme, ou quand l’assertion est en réalité un jugement sur la qualité de rédaction du message. Il y a aussi un cas plus simple : certains fournisseurs découragent activement l’inscription automatisée, et une suite qui contourne cela ne teste pas le produit, elle teste le contournement.
Le motif utile est un palier manuel explicite qui échoue bruyamment au lieu de passer en silence. Une étape qui dit « une personne doit vérifier ceci avant que l’exécution ne continue » est honnête ; une étape qui essaie et réussit occasionnellement ne l’est pas.
Une boîte jetable pour chaque exécution
La fixture la plus propre pour ce travail est une boîte créée pour le cas qui en a besoin et jetée ensuite. Comme rien d’autre n’y a jamais été envoyé, le message le plus récent est presque certainement le bon, et le problème de fraîcheur disparaît en grande partie.
La page de courrier temporaire crée une adresse à la demande : choisissez un domaine de messagerie, donnez-lui éventuellement un préfixe, et une boîte apparaît qui liste ce qui arrive. Les codes sont présentés séparément afin de pouvoir être copiés sans lire tout le corps, ce qui est pratique quand c’est une personne qui lit et utile à imiter quand c’est un logiciel.
Ces adresses sont un échafaudage pour une exécution de test. Elles ne représentent personne, elles sont jetées avec l’exécution, et elles ne doivent jamais être enregistrées comme une vraie identité ni utilisées comme le point de contact de quiconque.
Pour les développeurs : analyse, fraîcheur et plafonds de tentatives
Cinq décisions font la différence entre une suite qui lit des codes et une suite à laquelle on fait confiance sur ce point.
Donnez à chaque cas sa propre adresse, et faites porter à l’adresse l’identité du cas, afin qu’un message puisse être attribué par inspection plutôt que par chronologie.
Interrogez avec un plafond, et faites du plafond une partie du message d’échec. Quand il se déclenche, le rapport devrait indiquer quelle adresse a été lue, combien de messages elle contenait et quels objets ils portaient. Sans cela, la personne suivante relance le pipeline au lieu de le diagnostiquer.
Analysez de façon défensive. Prenez la correspondance la plus récente sur le destinataire et l’objet attendu, puis extrayez le code du contexte qui l’entoure. Si aucun code n’est trouvé, échouez avec le corps plutôt qu’avec un délai générique.
Ne désactivez jamais une limite de débit pour faire passer un test. La limite fait partie du comportement testé, et une suite qui la désactive ne décrit plus le produit que vos utilisateurs rencontrent. Gérez la limite à la place : choisissez une adresse qui n’a pas été utilisée récemment, et lisez le message existant plutôt que d’en demander un nouveau.
Gardez le chemin humain vivant. Pour les cas où l’automatisation ne peut réellement pas lire le code, documentez l’étape manuelle et rendez-la visible dans la sortie de l’exécution, afin qu’une vérification ignorée ne soit jamais prise pour une vérification réussie.
L’article sur les tests de parcours de vérification couvre le parcours autour du code, et comment fonctionne le courrier temporaire explique pourquoi un message lent ou dupliqué est normal plutôt que cassé.
Étapes suivantes
Trouvez l’étape de code dans votre suite et vérifiez les deux choses le plus souvent manquantes : si l’adresse est unique au cas, et si le message d’échec permettrait à quelqu’un d’autre de diagnostiquer l’exécution sans la répéter. Exécutez ensuite le même cas avec une adresse créée à neuf depuis la page de courrier temporaire et voyez si l’instabilité que vous tolériez disparaît.