Dans la dernière application que je suis en train de développer, un e-mail est envoyé au moment de l’inscription d’un utilisateur, il est donc logique d’ajouter un scénario Behat pour tester cette fonctionnalité. J’entends souvent qu’il n’est pas possible de tester fonctionnellement l’envoi d’email, je vous propose donc un exemple de scénario pour vérifier l’envoi du mail lors de l’inscription de l’utilisateur avec Behat.
Prenons l’étape qui nous interresse dans ce scénario:
Cette étape pose plusieurs problèmes:
- on doit d’abord être capable de récupérer l’ensemble des mails envoyés lors d’un scénario à un utilisateur
- on doit identifier les types de mails (registration, confirmation…)
Récupérer l’ensemble des mails
Avec SwiftMailer, il suffit de modifier la configuration (dans le fichier config_test.yml
) pour stocker les mails sur le disque au lieu de les envoyer, en utilisant le mode spool
de type file
.
Lorsque l’on rajoute cette configuration, ou peut récupérer le dossier qui permet de stocker les messages, à partir du paramètre swiftmailer.spool.file.path
depuis le container. Par défaut il s’agit du dossier %kernel.cache_dir%/swiftmailer/spool
.
Récupérer seulement les mails du scénario en cours
SwiftMailer va écrire un fichier par mail envoyé, pour récupérer uniquement ceux du scénario en cours, il suffit de vider le dossier qui contient ces mails avant le scénario.
Pour celà, on peut créer une méthode dans le fichier FeatureContext.php
et ajouter une annotation @BeforeScenario
sur cette méthode afin que cette dernière soit executée avant chaque scénario.
Identifier les type de mails
Pour identifier un mail, on ne peut pas se fier à son contenu, car celui-ci peut être internationalisé (donc traduit). J’ai choisi d’identifier les mails en ajoutant un en-tête personnalisé, car c’est une méthode très simple a appliquer avec SwiftMailer, il suffit d’une seul ligne de code. Cette méthode n’impacte en rien l’utilisateur qui recevra cet email.
Le code
Bien entendu, il faut écrire une étape personnalisée avec Behat (custom step) qui va faire tout le travail.
Conclusion
Et voilà une méthode simple et propre pour vous permettre de vérifier que votre application a bien donné l’ordre d’envoyer le mail.