Les tests d’e-mails transactionnels sont la discipline qui consiste à vérifier le courrier que votre produit envoie en son propre nom, avant que de vraies personnes ne le reçoivent. Une confirmation d’inscription, une réinitialisation de mot de passe, un avis de commande, une facture : chacun est déclenché par un événement, rempli à partir de données, et censé arriver exactement une fois. Les modes de défaillance sont banals et coûteux — un déclencheur qui ne se déclenche jamais, un gabarit qui affiche un nom vide, un lien qui pointe vers le mauvais environnement, une nouvelle tentative qui produit trois reçus identiques.
Qu’est-ce qui compte comme courrier transactionnel
Le courrier transactionnel est envoyé parce que quelque chose s’est produit, à une personne partie prenante de cet événement. Ce n’est ni une infolettre ni une promotion, et la distinction n’est pas académique : elle change quel contenu est approprié, ce que le destinataire attend, et ce que signifie un désabonnement en un clic dans chaque cas.
La frontière devient floue en pratique, et c’est dans ce flou que les problèmes commencent. Placer un bloc promotionnel dans une réinitialisation de mot de passe est une façon bien rodée d’agacer les gens. Envoyer une confirmation de commande via le pipeline marketing signifie qu’une suppression ou une préférence de désabonnement peut arrêter silencieusement un message dont le destinataire a réellement besoin.
Décidez à quel pipeline chaque message appartient, et rendez cette décision visible dans la configuration plutôt que dans la mémoire de quelqu’un.
Vérifier la liste des déclencheurs avant le lancement
Partez des événements, pas des gabarits. Pour chaque événement qui devrait produire du courrier, confirmez qu’un message est effectivement produit, envoyé à la bonne adresse, et reconnaissable comme appartenant à cet événement.
- Compte créé, confirmation d’adresse demandée, adresse modifiée.
- Réinitialisation de mot de passe demandée et mot de passe modifié.
- Commande passée, paiement réglé, remboursement émis.
- Facture ou reçu généré.
- Avis planifiés ou liés à la sécurité que le produit promet.
Pour chaque ligne, les questions sont les mêmes : se déclenche-t-il une seule fois, porte-t-il le bon destinataire, et survit-il à une nouvelle tentative ? Une liste de contrôle qui nomme l’événement vaut plus qu’une qui nomme le gabarit, car ce sont les événements qui disparaissent réellement.
Les variables s’affichent-elles toujours ?
L’affichage est l’endroit où un produit bien testé livre encore des défauts visibles, car un gabarit qui s’affiche correctement avec des données complètes peut s’afficher très différemment avec des données partielles.
Les cas qui valent la peine d’être essayés sont les cas vides. Un utilisateur avec un seul nom, un utilisateur sans nom d’affichage du tout, une commande avec une seule ligne d’article et une commande sans aucune, une valeur qui est une chaîne vide plutôt qu’absente. Chacun de ces cas devrait produire quelque chose qu’une personne peut lire, et aucun ne devrait produire de texte d’espace réservé brut ou un trou là où une phrase attendait un nom.
Deux habitudes aident. Donnez à chaque variable une valeur de repli définie, afin qu’une absence produise une phrase sensée plutôt que rien. Et affichez dans le même chemin de code que celui utilisé par le produit, afin que le test exerce le vrai gabarit plutôt qu’une copie qui diverge.
Que se passe-t-il quand le même événement se déclenche deux fois ?
Supposons que le prestataire de paiement appelle votre webhook deux fois, ou qu’une file redélivre un message parce qu’un accusé de réception a été perdu. L’utilisateur ne devrait pas recevoir deux reçus pour une seule commande.
C’est une propriété du côté expéditeur plutôt que du serveur de messagerie, et elle vaut la peine d’être testée directement : livrez le même événement deux fois et affirmez qu’un seul message en résulte. Le mécanisme habituel est un identifiant fourni par l’événement, enregistré lorsque le message est accepté, afin que la seconde livraison soit reconnue comme une répétition. Quel que soit le mécanisme, le test devrait l’exercer plutôt que de le supposer, car les événements en double sont normaux dans les systèmes distribués et le courrier n’a aucun moyen d’annuler un message envoyé.
Pourquoi l’identité d’envoi importe-t-elle aux boîtes de réception ?
Parce que les systèmes récepteurs décident s’il faut faire confiance à un message en partie d’après l’endroit d’où il semble provenir. Le domaine d’envoi est normalement configuré avec des enregistrements d’autorisation et de signature publiés dans le système de noms de domaine, et ces enregistrements sont ce qui permet au récepteur de savoir que le message vient réellement du domaine qu’il revendique. Les mécanismes sont normalisés dans des documents de l’IETF ; le point opérationnel est qu’un domaine configuré pour du trafic web ordinaire n’est pas automatiquement configuré pour envoyer du courrier, et un lancement qui saute cette étape peut produire des messages qui ressemblent à du spam dès le premier jour.
Le configurer est le travail de celui qui possède le domaine, et les détails dépendent du fournisseur de messagerie. Ce qu’une liste de contrôle de test peut faire, c’est confirmer que la configuration a réellement été menée à bien dans l’environnement que vous lancez, et pas seulement dans celui où vous avez testé.
Localisation, formats de date et différences entre pays
Un produit qui sert plus d’un marché hérite de deux erreurs faciles. La première est le texte : un message localisé dans le corps mais dont l’objet et le pied de page sont restés dans la langue d’origine. La seconde est le format : une date qui se lit sans ambiguïté sur un marché et de façon déroutante sur un autre, ou un nombre formaté avec un séparateur décimal différent de celui attendu par le destinataire.
La vérification concrète consiste à déclencher chaque message dans toutes les langues que le produit livre et à lire tout le message, objet compris, comme le ferait un destinataire. Si le contenu fait référence à un détail propre à une juridiction — un format d’identifiant, un libellé fiscal, une convention postale —, les pages du marché concerné sont une référence utile pour ce que ce marché attend, comme pour l’Allemagne ou le Japon.
Quoi que vous envoyiez dans cette passe de test, cela doit aller à des adresses que vous avez créées dans ce but. Rien de ce qui est décrit ici n’est une vraie identité ni un contact client réel, et aucun gabarit ne devrait être livré avec l’adresse d’une vraie personne dedans.
Pour les développeurs : idempotence, gestion des échecs et journaux
Quatre propriétés méritent une couverture explicite dans la suite.
L’idempotence d’abord : un événement, un message, quel que soit le nombre de fois que l’événement est livré. Affirmez-le en livrant deux fois.
La gestion des échecs ensuite : décidez ce qui se passe quand le fournisseur de messagerie refuse ou dépasse le délai. Un envoi échoué devrait être enregistré, retenté selon un calendrier, et remonté — pas avalé. Un échec silencieux signifie découvrir le problème par un client.
Les valeurs de repli des gabarits troisièmement : définissez ce que chaque variable affiche lorsqu’elle est absente, et testez le cas absent. C’est la classe de défauts qui atteint le plus souvent la production, car des données de test complètes la masquent.
Les journaux quatrièmement : conservez assez d’informations pour diagnostiquer un message manquant, mais pas au point que le journal devienne un passif de données. Enregistrez l’identifiant de l’événement, la version du gabarit et le résultat. Ne journalisez pas le corps du message, et ne journalisez pas un lien de réinitialisation, car une ligne de journal contenant un lien fonctionnel est un identifiant d’authentification à longue durée de conservation.
Pour le courrier que vos tests eux-mêmes génèrent, une adresse créée pour l’exécution garde les assertions étroites et tient les boîtes des autres hors de la boucle ; l’outil de courrier temporaire en crée une en quelques secondes, et comment fonctionne le courrier temporaire explique ce qu’il advient des messages ensuite.
Étapes suivantes
Reprenez la liste des déclencheurs ci-dessus et marquez chaque ligne avec l’environnement où vous l’avez vue fonctionner en dernier et la personne qui a lu le message en dernier. Tout ce qui n’est pas marqué est un risque de lancement. Envoyez-vous ensuite chaque message depuis une adresse créée pour le test sur la page de courrier temporaire, et lisez-le comme le ferait un destinataire — sur l’objet autant que dans le corps.