Un stagiaire, testant un nouveau workflow de réinitialisation de mot de passe sur l’environnement de recette d’un client, a par erreur déclenché l’envoi de dix-sept emails vers de vraies adresses clientes stockées en base, l’environnement de recette pointant encore vers le serveur SMTP de production suite à une copie de configuration mal filtrée. Rien de dramatique dans ce cas précis, mais l’incident a suffi à imposer une règle stricte : aucun environnement de test, qu’il soit local ou en CI, ne doit jamais pouvoir envoyer un email vers l’extérieur, point final.
Mailpit répond exactement à ce besoin : un serveur SMTP factice, léger, qui capture tous les emails envoyés sans jamais les transmettre réellement, et qui expose à la fois une interface web pour les consulter visuellement et une API HTTP pour les interroger automatiquement depuis une suite de tests.
Configurer WordPress pour envoyer vers Mailpit
WordPress utilise wp_mail() comme point d’entrée unique pour tous ses envois d’emails, qu’il s’agisse d’une notification de commande WooCommerce ou d’un email de réinitialisation de mot de passe. Rediriger ces envois vers Mailpit ne demande aucune modification du code de l’extension testée, seulement une configuration SMTP pointée vers l’instance Mailpit, via un plugin comme WP Mail SMTP ou une simple configuration de PHPMailer dans un fichier de configuration de test :
add_action( 'phpmailer_init', function ( $phpmailer ) {
$phpmailer->isSMTP();
$phpmailer->Host = 'mailpit';
$phpmailer->Port = 1025;
$phpmailer->SMTPAuth = false;
$phpmailer->SMTPSecure = false;
} );En local comme en CI, Mailpit se lance en une commande, ou via un conteneur dédié dans le fichier docker-compose.yml du projet, ce qui garantit que le même point de configuration fonctionne identiquement sur les deux environnements.
Interroger l’API Mailpit depuis un test PHPUnit
Mailpit expose une API REST simple, sans authentification par défaut sur un environnement de test isolé, qui permet de lister les messages reçus et de récupérer leur contenu détaillé. On l’utilise directement dans un test d’intégration pour vérifier qu’un email attendu a bien été envoyé, avec le bon destinataire et le bon contenu :
public function test_email_reinitialisation_envoye() {
$this->vider_boite_mailpit();
$utilisateur = $this->factory()->user->create( [ 'user_email' => 'client@example.test' ] );
retrieve_password( get_userdata( $utilisateur )->user_login );
$reponse = wp_remote_get( 'http://mailpit:8025/api/v1/messages' );
$messages = json_decode( wp_remote_retrieve_body( $reponse ), true );
$this->assertCount( 1, $messages['messages'] );
$this->assertSame( 'client@example.test', $messages['messages'][0]['To'][0]['Address'] );
$this->assertStringContainsString(
'réinitialiser votre mot de passe',
$messages['messages'][0]['Snippet']
);
}La méthode vider_boite_mailpit(), appelée en début de test via l’appel DELETE de l’API sur /api/v1/messages, garantit que chaque test part d’une boîte vide, condition indispensable pour éviter qu’un email envoyé par un test précédent fausse le comptage du test suivant.
Vérifier le contenu HTML, pas seulement la présence de l’email
Un email dont le contenu HTML est cassé, un tableau de commande mal fermé, une image manquante, une balise non fermée qui fait s’effondrer toute la mise en page dans certains clients de messagerie, ne se détecte pas en vérifiant simplement qu’un email a été envoyé. On récupère le corps HTML complet via l’endpoint dédié de l’API Mailpit et on y applique des assertions ciblées :
$corps_html = wp_remote_retrieve_body(
wp_remote_get( "http://mailpit:8025/api/v1/message/{$id_message}" )
);
$this->assertStringContainsString( '<table', $corps_html );
$this->assertStringNotContainsString( '{{', $corps_html ); // Aucun espace réservé de template oublié
Cette dernière assertion sur les accolades doubles a une vraie utilité pratique : elle détecte les templates d’emails qui utilisent un moteur de gabarit et qui laisseraient passer un espace réservé non résolu en cas d’erreur de variable, un défaut qui reste sinon invisible tant que personne n’ouvre l’email généré.
Intégrer Mailpit à un scénario E2E complet
Pour un test Playwright qui simule un parcours de commande complet, on peut interroger directement l’API Mailpit à la fin du scénario pour vérifier que l’email de confirmation de commande a bien été déclenché, avec le bon numéro de commande dans le contenu, sans avoir besoin de simuler une vraie boîte de réception :
- Vider la boîte Mailpit au début du scénario, via l’API DELETE
- Dérouler le parcours de commande normalement jusqu’à la confirmation
- Interroger l’API Mailpit et vérifier la présence d’un email contenant le numéro de commande affiché à l’écran
Un environnement de test qui peut, même accidentellement, envoyer un vrai email n’est pas un simple détail de configuration : c’est un risque de confidentialité et de confiance client qui mérite d’être éliminé structurellement, pas seulement surveillé.
En résumé
Mailpit règle en même temps deux problèmes distincts : la sécurité, en garantissant qu’aucun email de test ne peut atteindre une vraie adresse, et la fiabilité des tests, en donnant un accès programmatique simple au contenu réel des emails envoyés. La mise en place ne demande qu’une configuration SMTP redirigée et quelques appels à une API HTTP déjà bien documentée, pour un gain de confiance qui dépasse largement cet effort initial.
