Vos tests gardent leur forme
Le coût d'un changement d'outil de test d'e-mails n'est pas l'abonnement : c'est la journée passée à réécrire des assertions qui marchaient. Ici, seules les lignes qui parlent à l'ancien service changent. Votre test attend toujours un message, et affirme toujours quelque chose sur son contenu.
Ce que la migration demande
-
Quelques lignes par fichier : le client, et l'appel qui attend le message.
-
Rien à exporter : des messages de test se régénèrent au prochain passage de la suite.
-
Les deux outils en parallèle le temps de comparer, sans rien résilier.
Le même test, chez l'un puis chez l'autre
L'exemple part de Mailosaur. Depuis Mailtrap, MailSlurp, Mailisk ou Mailpit, la forme est la même : la page de chaque outil donne la correspondance.
// Le client Mailosaur, et le code cherché dans le corps.
const MailosaurClient = require('mailosaur');
const mailosaur = new MailosaurClient(process.env.MAILOSAUR_API_KEY);
// Attend le premier message qui correspond, 10 secondes par défaut.
const message = await mailosaur.messages.get(serverId, {
sentTo: address,
});
const code = message.html.codes[0].value;// Aucun paquet Facteur à installer : un appel HTTP qui attend.
const search = new URLSearchParams({
inbox: 'j3k9x2mq',
sentTo: address,
wait: '30000',
});
const response = await fetch('https://api.facteur.eu/v1/messages?' + search, {
headers: { authorization: 'Bearer ' + process.env.FACTEUR_API_KEY },
});
const { messages } = await response.json();
// Le code est déjà extrait, dans un champ à part.
const code = messages[0].otp;En HTTP aujourd'hui, avec une bibliothèque plus tard
La bibliothèque fera gagner du confort, pas des capacités : tout ce qu'elle fait, un appel HTTP le fait aussi.
-
L'appel direct : une requête GET sur /v1/messages avec un paramètre wait en millisecondes, cinq minutes au plus. La réponse arrive quand le message arrive.
-
La bibliothèque @facteur-eu/sdk est écrite, avec un appel waitFor qui attend le message, mais elle n'est pas encore publiée sur npm. Elle le sera après la mise en service de l'API.
-
Les versions déjà présentes sous ce nom sur npm visent une ancienne API de Facteur : ne les installez pas.
Cinq étapes, aucune irréversible
-
Étape 01
Créez un compte et une inbox
Une inbox est une boîte qui reçoit, que vos tests interrogent par son identifiant. L'offre gratuite suffit pour valider la migration, et ne demande pas de carte bancaire.
-
Étape 02
Posez la clé d'API dans votre environnement
Sous le nom FACTEUR_API_KEY, à côté de celle de votre outil actuel. Les deux cohabitent : rien ne vous demande de retirer l'ancienne avant d'être convaincu.
-
Étape 03
Basculez un seul test
Celui qui vous coûte le plus quand il est instable. Quelques lignes à changer, puis vous le lancez : s'il passe, votre suite passera.
-
Étape 04
Faites tourner les deux suites en parallèle
Une semaine, le temps de comparer les taux de réussite sur vos propres tests plutôt que sur une page de vente. C'est aussi ce qui rend le retour en arrière gratuit.
-
Étape 05
Posez vos plafonds et vos alertes
Sur les offres payantes, un plafond de messages par inbox, et des seuils qui préviennent par e-mail avant de l'atteindre : un test parti en boucle s'arrête sur sa propre limite au lieu de consommer le volume de toute l'équipe.
Ce qui est propre à l'outil que vous quittez
Chaque page reprend ce que l'outil publie, sourcé et daté, et la correspondance de ses appels.
Mailisk
Deux API qui attendent le message : l'adresse change, et le code arrive extrait.
Mailtrap
Passer d'un bac à sable qui intercepte à une inbox qui reçoit.
MailSlurp
Ce que devient une boîte créée puis supprimée à chaque test.
Mailpit
Quitter un service local : ce que vous retirez de la chaîne d'intégration.
Mailosaur
La correspondance des appels de l'API, un par un, et ceux qui n'ont pas d'équivalent.
Ce que votre outil fait peut-être, et Facteur pas encore
Écrit ici plutôt que découvert au milieu d'une migration. Si votre suite dépend de l'un de ces points, écrivez-nous : nous vous dirons si la migration a du sens aujourd'hui, ou pas.
-
Le téléchargement du message brut au format .eml n'existe pas dans l'API publique.
-
L'analyse de délivrabilité (SPF, DKIM, DMARC, note de spam) n'existe pas.
-
Les aperçus de rendu dans plusieurs clients de messagerie et l'éditeur visuel de modèles n'ont pas d'équivalent, et n'en auront pas : ce n'est pas le même produit.
-
Les inboxes SMS existent, mais le raccordement à l'opérateur n'est pas en service : aucun SMS réel n'arrive aujourd'hui.
Questions fréquentes
Combien de lignes changent, vraiment ?
Celles qui parlent à l'ancien service : la construction du client et l'appel qui attend le message. L'assertion raccourcit souvent, parce que le code à usage unique arrive déjà extrait dans un champ du message. Ce qui ne change pas, c'est la structure du test.
Faut-il tout basculer d'un coup ?
Non, et c'est le seul conseil de cette page. Basculez un test, gardez les deux outils une semaine, comparez sur vos propres suites. Rien dans la migration n'est irréversible avant que vous ne résiliiez l'autre abonnement, et cette décision reste la vôtre.
Que deviennent les messages déjà reçus chez l'autre service ?
Ils restent chez lui, et c'est ce qui rend la migration légère : ce sont des messages de test, ils se régénèrent au prochain passage de votre suite. Il n'y a rien à exporter et aucune bascule DNS à planifier.
Et si mon outil n'est pas dans la liste des cinq ?
La marche à suivre de cette page ne dépend pas de l'outil que vous quittez : un client, un appel qui attend, une assertion. Écrivez-nous le nom de l'outil et nous vous dirons ce qui se transpose, avant que vous n'ouvriez un compte.
Basculez un test, pas une suite
L'offre gratuite ne demande pas de carte bancaire. Un fichier, quelques lignes, et vous saurez.