Intégration Nodemailer

Tester les emails Nodemailer avec InboxTap

InboxTap accepte le même message SMTP qu’une application Nodemailer enverrait à un fournisseur de livraison, mais le capture dans une mémoire locale bornée au lieu de le relayer. La configuration officielle fournit un transport prêt à l’emploi et des paramètres SMTP dynamiques afin que les tests exercent la véritable construction du message sans ports fixes.

IntégrationsMaintenu par contributeursDernière mise à jour 24 juillet 2026

Configurer correctement le SMTP local simple

Un transport Nodemailer manuel pour InboxTap utilise l’hôte et le port locaux, secure: false, ignoreTLS: true et aucun objet auth. secure: false signifie que TLS n’est pas actif à l’ouverture de la connexion ; cette option seule n’empêche pas Nodemailer de tenter ensuite un passage à STARTTLS.

InboxTap désactive l’authentification et STARTTLS, car il s’agit d’un serveur de capture limité à l’interface de bouclage. Séparez ces paramètres de développement du transport authentifié et chiffré utilisé pour les livraisons en production.

Documentation du transport SMTP Nodemailer ↗

Préférer la configuration vérifiée

startInboxTapFixture() choisit des ports SMTP et API libres, démarre le serveur, crée un transport Nodemailer, appelle verify() et contrôle le point d’état d’InboxTap avant de rendre la main. Sa méthode close() peut être appelée plusieurs fois sans risque et nettoie le transport comme les écouteurs.

Le transport fourni convient aux tests d’intégration centrés sur les modèles. Pour tester le service d’email détenu par l’application, configurez-le avec inboxTap.smtp et déclenchez l’envoi depuis l’API applicative.

email.test.ts

import { startInboxTapFixture } from "inboxtap/fixtures";

const inboxTap = await startInboxTapFixture();

try {
  const inbox = await inboxTap.createInbox();

  await inboxTap.transport.sendMail({
    from: "app@local.test",
    to: inbox.address,
    subject: "Account",
    text: "https://app.local.test/verify",
  });

  const email = await inbox.waitForMessage();
  expect(email.envelope.to).toContain(inbox.address);
} finally {
  await inboxTap.close();
}

Comprendre ce que prouve la vérification du transport

La méthode verify() de Nodemailer contrôle la résolution DNS, la connexion TCP, l’éventuelle montée en TLS et l’authentification sans envoyer de message. Elle ne prouve pas qu’un serveur acceptera un expéditeur d’enveloppe ou un message particulier.

Conservez au moins une véritable transaction sendMail() dans le test. InboxTap ne stocke le message qu’après la réussite complète de SMTP DATA : le CapturedEmail obtenu représente donc une livraison acceptée, et pas seulement un transport disponible.

Vérification du transport Nodemailer ↗

Vérifier l’enveloppe et le contenu

Utilisez toHaveRecipient() lorsque l’acheminement compte, car cette assertion compare l’enveloppe SMTP plutôt qu’une adresse d’affichage extraite de l’en-tête. Utilisez toContainLink() pour les URL HTTP ou HTTPS extraites et waitForCode() pour une valeur numérique.

Choisissez waitForMessage() lorsque le test a besoin du sujet, des en-têtes normalisés, du texte, du HTML, de la source brute ou de tous les liens extraits. Évitez d’afficher le corps ou les URL porteuses de jetons dans les diagnostics courants.

Fermer chaque propriétaire de ressource

Placez fixture.close() dans un bloc finally lorsque vous gérez explicitement le cycle de vie. Si l’application crée son propre transport Nodemailer, sa configuration de test doit fermer ce transport avant l’arrêt d’InboxTap.

Les adaptateurs natifs de Bun, Vitest et Playwright automatisent cet ordre. Une attribution explicite de chaque ressource empêche des connexions ouvertes de maintenir le processus de test en vie après un échec.

Relier un véritable expéditeur applicatif

Poursuivez avec un parcours Express et Vitest exécutable qui teste les liens, les jetons personnalisés, les OTP, les destinataires et les en-têtes.

Lire le guide Nodemailer