Traduit automatiquement de l’anglais.

Lire en anglais
Proxy Mail QA
Créer un compteOuvrir l'application

Tests et CI

Des tests d’inscription qui attendent le vrai e-mail.

Vos tests de bout en bout s’inscrivent comme un vrai utilisateur, puis obtiennent le code ou le lien en un seul appel. Vérifiez l’e-mail lui-même, donnez à vos tests parallèles leurs propres comptes, et consultez les e-mails de chaque exécution sur la pull request.

Créer un compte gratuitOuvrir l'applicationLire la documentation développeur

Formule Free · npm, Python et REST · Playwright, Cypress, Selenium et plus

Fonctionnement

Un seul appel là où le test bloquait.

  1. Créer une adresse

    Un appel crée une adresse de test avec un persona fictif et un mot de passe, ou fournit la valeur de chaque champ de votre formulaire. Dans CI, une adresse peut servir à toute une exécution, avec un plus-tag par test.

  2. Inscrivez-vous dans votre application

    Votre test remplit le formulaire avec Playwright, Cypress, Selenium ou tout autre outil, et note l’heure de l’envoi.

  3. Attendez le code ou le lien

    L’attente se termine dès l’arrivée de l’e-mail, avec uniquement le code ou le lien. Les e-mails antérieurs à l’envoi du test sont ignorés.

  4. Terminez le parcours

    Saisissez le code ou ouvrez le lien, et vérifiez que l’utilisateur est connecté. Si rien n’est arrivé, l’erreur en donne la raison, dans la mesure du possible.

Dans vos tests

Quelques lignes dans le test que vous avez déjà.

Le package npm pour Node.js, un helper Python sans rien à installer, et l’REST API pour tout le reste. Des exemples complets pour chaque outil figurent dans la documentation développeur.

Playwright avec le paquet npm

signup.spec.ts
import { test, expect } from '@playwright/test';
import { ProxyMailQA } from 'proxymail-qa';

const qa = new ProxyMailQA(); // reads PROXYMAIL_QA_API_KEY

test('sign-up sends a working code', async ({ page }) => {
  const { address, password } = await qa.createAddress({ password: true });
  await page.goto('/sign-up');
  await page.getByLabel('Email').fill(address);
  await page.getByLabel('Password').fill(password);

  const submitted = new Date();
  await page.getByRole('button', { name: 'Sign up' }).click();

  const { value: code } = await qa.waitForCode(address, { since: submitted });
  await page.getByLabel('Code').fill(code);
  await expect(page.getByText('Welcome')).toBeVisible();
});

pytest avec l’utilitaire Python

test_signup.py
import re

from playwright.sync_api import expect
from proxymail_qa import create_address, now, wait_for_link


def test_sign_up_verifies_the_email(page):
    account = create_address()
    page.goto("/signup")
    page.get_by_label("Email").fill(account["address"])
    page.get_by_label("Password").fill(account["password"])

    submitted = now()
    page.get_by_role("button", name="Sign up").click()

    page.goto(wait_for_link(account["address"], since=submitted))
    expect(page).to_have_url(re.compile("verified"))

Ce que les tests peuvent vérifier

Plus que « le code est-il arrivé ».

Codes et liens

Codes de vérification et de connexion, et liens de vérification, de connexion magique, d’invitation et de réinitialisation, uniquement parmi les e-mails envoyés après l’envoi du test.

Rien n’est arrivé, ou un seul

Prouvez qu’un utilisateur désabonné n’a reçu aucune newsletter, et repérez une inscription qui envoie deux e-mails de vérification au lieu d’un.

L’envoi et la construction de l’e-mail

SPF, DKIM et DMARC, les liens vers localhost ou en http simple, un lien qui pointe vers la production au lieu de la préproduction, une expiration manquante, l’affichage sur téléphone, et le texte et la langue attendus.

Un pool de comptes

Taguez les comptes selon leur état et laissez chaque test en emprunter un. Vos propres hooks en créent un quand aucun n’est libre, confirment son état et le rendent. Les tests parallèles n’en partagent jamais.

Un rapport sur la pull request

Quels e-mails sont arrivés et à quelle vitesse, de quel test chacun provient, les codes et liens, ce qui a échoué, et ce qui a changé depuis les dernières exécutions : e-mails plus lents, e-mails en trop, tests instables.

Pourquoi un e-mail manque

Quand une attente revient vide, l’erreur en donne la raison dans la mesure du possible, par exemple un fournisseur d’e-mails en mode sandbox qui n’envoie qu’aux adresses vérifiées.

Sur la pull request

Les e-mails de chaque exécution, là où vous relisez le code.

Ajoutez l’action Proxy Mail QA avant vos tests. Le package npm et le helper Python ajoutent à l’exécution ce qu’ils observent, et l’action publie le rapport à la fin du job, réussi ou non. Avec la fixture et le reporter Playwright, ou les hooks pytest, elle indique aussi de quel test provient chaque e-mail et quels tests ont échoué.

.github/workflows/e2e.yml
jobs:
  e2e:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v7
      - uses: aaquib90/proxymail-qa-action@v1
        with:
          api-key: ${{ secrets.PROXYMAIL_QA_API_KEY }}
      - run: npm ci
      - run: npx playwright test
        env:
          PROXYMAIL_QA_API_KEY: ${{ secrets.PROXYMAIL_QA_API_KEY }}
Lire le guide CI

Exécutions depuis d’autres systèmes CI

Conçu pour la CI

Sans risque à chaque push.

  • Sa propre clé

    Donnez à la CI son propre projet ou sa propre clé, conservée dans les secrets de votre système CI. La révoquer n’affecte rien d’autre.

  • Une adresse par exécution

    Les e-mails envoyés à nom+nimportequoi@ arrivent à nom@, et une attente sur une adresse taguée ne trouve que ses propres e-mails : un pipeline chargé reste bien en deçà des limites quotidiennes.

  • Workers en parallèle

    Une attente compte pour une requête, quelle que soit sa durée. Les clés peuvent faire 60 requêtes par minute avec Free et 600 avec Team.

  • Le rapport ne conserve aucun texte d’e-mail

    Une exécution conserve les adresses, codes, durées, résultats de vérification, noms et erreurs des tests échoués, ainsi que le site et le chemin de chaque lien, avec les parties ressemblant à des jetons masquées. Jamais le texte ni l’objet d’un e-mail, ni la query d’un lien. Les exécutions sont conservées 90 jours.

  • Les forks n’ont pas accès aux secrets

    Sur une pull request issue d’un fork, l’action affiche un avertissement et ne lance aucune exécution : votre clé n’atteint jamais du code que vous n’avez pas relu.

  • Sites de test uniquement

    Proxy Mail QA sert aux versions de développement, de staging, de QA, de prévisualisation et locales d’apps que vous créez ou êtes autorisé à tester, jamais aux versions en production.

FAQ

Questions

Les tests peuvent-ils vérifier les coupons et le désabonnement ?

Oui. Attendez un coupon avec sa remise et sa date de fin, enregistrez ce que le paiement en a fait, vérifiez qu’une même personne ne peut pas profiter deux fois d’une offre, et marquez une adresse comme désabonnée pour que tout marketing ultérieur échoue. Voir e-mails marketing et d’offres.

Avec quels outils de test fonctionne-t-il ?

Tout ce qui peut faire une requête HTTP. Le package npm couvre les test runners Node.js comme Playwright, Cypress et Puppeteer, le helper Python couvre pytest avec Selenium ou Playwright, et de petits helpers pour XCUITest, Espresso, Flutter, Maestro, Detox et Appium vérifient les e-mails, utilisent le pool de comptes et alimentent aussi le rapport de l’exécution. Tout le reste utilise l’REST API.

Ai-je besoin de la formule Team ?

Non. Le package npm, le helper Python, l’REST API, l’Action GitHub, les exécutions et le pool de comptes sont disponibles avec chaque formule. Les clés Free font 60 requêtes par minute, un compte Free dispose de 500 adresses au total (jusqu’à 50 par jour), et les plus-tags permettent à une adresse de servir toute une exécution. Team n’a pas de limite d’adresses et porte la limite de requêtes à 600 par minute.

Le rapport fonctionne-t-il en dehors de GitHub Actions ?

Oui. Lancez une exécution avec l’API (qa.startRun() dans le package npm, start_run() dans Python), envoyez son id avec chaque appel, terminez-la, et récupérez le rapport en Markdown pour le publier là où vous relisez le code.

Qu’est-ce qui fait échouer une exécution ?

Un e-mail attendu par un test qui n’est jamais arrivé, un e-mail arrivé alors qu’aucun ne devait arriver, une vérification d’e-mail échouée, un test échoué enregistré par le reporter, du marketing après désabonnement, une personne recevant une offre deux fois, un coupon accepté alors qu’il ne devrait pas l’être, ou une note qui l’indique. L’action peut alors aussi faire échouer le job, même si les tests ont réussi, avec fail-job réglé sur true.

Mon agent de codage peut-il utiliser le même pool de comptes ?

Oui. Les agents connectés au MCP server empruntent et rendent des comptes du pool du même projet : un agent et votre suite de tests n’utilisent jamais le même compte en même temps.

Autres fonctionnalités

Faites attendre le vrai e-mail à votre prochain test d’inscription.

Créez un compte gratuit, générez une clé d'API dans les paramètres du projet, et ajoutez une attente à un test existant.

Créer un compte gratuitOuvrir l'application

Une question sur cette page ?

Posez votre question dans la langue de votre choix. La documentation peut y répondre tout de suite, ou vous pouvez l'envoyer à l'équipe Proxy Mail QA, qui répond en anglais.

Interroger la documentation