# Tester les emails dans Cypress

> Un test Cypress qui attend un email et lit le code qu’il contient, avec la clé d’API gardée hors du navigateur. Sans cy.wait arbitraire.
> https://facteur.eu/tester-les-emails-avec-cypress

## Attendre un email sans cy.wait

Cypress exécute votre test dans le navigateur, ce qui pose deux problèmes pour lire un email : la clé d’API ne doit pas s’y trouver, et l’appel réseau dépend de l’origine de la page testée. Une tâche Node règle les deux.

## La configuration, puis le test

La tâche vit dans le processus Cypress, là où la clé peut rester. Le test, lui, ne voit qu’une commande.

### La clé reste côté Node

Votre spec est servie à une page : une clé écrite dedans serait une clé dans le JavaScript d’une page. La tâche la garde de l’autre côté.

### cy.task rend une valeur, donc la chaîne continue

Le message revient dans le flux de commandes habituel, et .should() se comporte comme sur un cy.get().

### Le numéro de tentative est dans l’adresse

Sans lui, un test rejoué relit l’email de sa première tentative et passe pour une mauvaise raison, précisément quand quelque chose est déjà instable.

## Pourquoi il n’y a pas de cy.wait

## L’application qui envoie cet email

Reste à avoir une application qui envoie le message que ce test attend. La Belle Étoile en est une, ouverte à tout le monde : commandez-y une lampe, donnez l’adresse de votre boîte de test, et la confirmation arrive avec son code. Elle sert huit parcours, dont un qui n’envoie rien du tout : c’est celui qui éprouve un test censé vérifier qu’aucun email n’est parti. Elle n’écrit qu’à une adresse Facteur, ce qui l’empêche de servir de relais à qui que ce soit.

## Le greffon Cypress, si vous le voulez

Il s’installe en une ligne : npm i -D cypress-facteur. La version ci-dessus reste celle qui ne demande rien à installer, en une trentaine de lignes que vous gardez.