Tests und CI
Registrierungstests, die auf die echte E-Mail warten.
Deine End-to-End-Tests registrieren sich wie ein echter Nutzer und holen dann mit einem Aufruf den Code oder Link. Prüfe die E-Mail selbst, gib parallelen Tests eigene Konten und sieh die E-Mails jedes Runs im Pull-Request.
Free-Tarif · npm, Python und REST · Playwright, Cypress, Selenium und mehr
So funktioniert es
Ein Aufruf, wo der Test früher hing.
Adresse erstellen
Ein Aufruf erstellt eine Testadresse mit einer fiktiven Persona und einem Passwort oder liefert den Wert für jedes Feld deines Formulars. In CI kann eine Adresse einen ganzen Run bedienen, mit einem Plus-Tag pro Test.
In deiner App registrieren
Dein Test füllt das Formular mit Playwright, Cypress, Selenium oder etwas anderem aus und merkt sich den Zeitpunkt des Absendens.
Auf Code oder Link warten
Das Warten endet, sobald die E-Mail ankommt, und liefert nur den Code oder Link. Mails von vor dem Absenden werden ignoriert.
Flow abschließen
Gib den Code ein oder öffne den Link und prüfe, ob der Nutzer angemeldet ist. Kam nichts an, sagt der Fehler, warum, soweit wir es erkennen können.
In deinen Tests
Ein paar Zeilen in dem Test, den du schon hast.
Das npm-Paket für Node.js, ein Python-Helper ohne Installation und die REST API für alles andere. Vollständige Beispiele für jedes Tool findest du in der Developer-Doku.
Playwright mit dem npm-Paket
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 mit dem Python-Helper
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"))Was Tests prüfen können
Mehr als „Ist der Code angekommen?“.
Codes und Links
Verifizierungs- und Login-Codes sowie Verifizierungs-, Magic-Sign-in-, Einladungs- und Reset-Links, nur aus Mails, die nach dem Absenden kamen.
Nichts kam an – oder doch
Weise nach, dass ein abgemeldeter Nutzer keinen Newsletter bekam, und erkenne eine Registrierung, die zwei Verifizierungs-E-Mails statt einer sendet.
Versand und Aufbau der E-Mail
SPF, DKIM und DMARC, Links zu localhost oder reinem http, ein Link zur Produktion statt zu Staging, ein fehlendes Ablaufdatum, ob sie aufs Handy passt, und der erwartete Text und die Sprache.
Ein Konten-Pool
Versieh Konten mit ihrem Zustand und lass jeden Test eines ausleihen. Deine eigenen Hooks erstellen eines, wenn keines frei ist, bestätigen seinen Zustand und geben es zurück. Parallele Tests teilen sich nie eines.
Ein Bericht im Pull Request
Welche E-Mails ankamen und wie schnell, von welchem Test jede kam, die Codes und Links, was fehlschlug und was sich seit den letzten Runs geändert hat: langsamere E-Mails, zusätzliche E-Mails, instabile Tests.
Warum Mails fehlen
Kommt ein Warten leer zurück, sagt der Fehler, warum, soweit wir es erkennen können, etwa ein E-Mail-Dienst im Sandbox-Modus, der nur an verifizierte Adressen sendet.
Im Pull-Request
Die E-Mails jedes Runs, dort, wo du den Code reviewst.
Füg die Proxy Mail QA-Action vor deinen Tests hinzu. Das npm-Paket und der Python-Helper fügen dem Run hinzu, was sie sehen, und die Action postet den Bericht am Ende des Jobs, ob bestanden oder nicht. Mit der Playwright-Fixture und dem Reporter oder den pytest-Hooks zeigt sie auch, von welchem Test jede E-Mail kam und welche Tests fehlschlugen.
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 }}Gemacht für CI
Sicher bei jedem Push.
-
Ein eigener Schlüssel
Gib CI ein eigenes Projekt oder einen eigenen Schlüssel, gespeichert in den Secrets deines CI-Systems. Ein Widerruf betrifft nichts anderes.
-
Eine Adresse pro Run
Mails an name+beliebig@ kommen bei name@ an, und ein Warten auf eine getaggte Adresse findet nur deren eigene Mails. So bleibt auch eine viel genutzte Pipeline weit unter den Tageslimits.
-
Parallele Worker
Ein Warten ist eine Anfrage, egal wie lange es dauert. Schlüssel machen im Free-Tarif 60 Anfragen pro Minute, im Team-Tarif 600.
-
Der Bericht speichert keinen E-Mail-Text
Ein Run speichert die Adressen, Codes, Zeiten, Prüfergebnisse, Namen und Fehler fehlgeschlagener Tests sowie Website und Pfad jedes Links, mit verborgenen tokenartigen Teilen. Nie den Text oder Betreff einer E-Mail oder die Query eines Links. Runs werden 90 Tage aufbewahrt.
-
Forks bekommen keine Secrets
Bei einem Pull-Request aus einem Fork warnt die Action und startet keinen Run, sodass dein Schlüssel nie Code erreicht, den du nicht geprüft hast.
-
Nur Testseiten
Proxy Mail QA ist für Entwicklungs-, Staging-, QA-, Preview- und lokale Versionen von Apps, die du baust oder testen darfst, nie für Live-Apps.
FAQ
Fragen
Können Tests Gutscheine und Abmeldungen prüfen?
Ja. Warte auf einen Gutschein mit Rabatt und Enddatum, halte fest, was der Checkout damit gemacht hat, prüfe, dass eine Person ein Angebot nicht zweimal einlösen kann, und markiere eine Adresse als abgemeldet, damit späteres Marketing fehlschlägt. Siehe Marketing- und Angebots-E-Mails.
Mit welchen Test-Tools funktioniert es?
Mit allem, was eine HTTP-Anfrage senden kann. Das npm-Paket deckt Node.js-Test-Runner wie Playwright, Cypress und Puppeteer ab, der Python-Helper deckt pytest mit Selenium oder Playwright ab, und kleine Helper für XCUITest, Espresso, Flutter, Maestro, Detox und Appium prüfen E-Mails, nutzen den Konten-Pool und tragen ebenfalls zum Bericht des Runs bei. Alles andere nutzt die REST API.
Brauche ich den Team-Tarif?
Nein. Das npm-Paket, der Python-Helper, die REST API, die GitHub Action, Runs und der Konten-Pool sind in jedem Tarif enthalten. Free-Schlüssel machen 60 Anfragen pro Minute, ein Free-Konto hat insgesamt 500 Adressen (bis zu 50 pro Tag), und dank Plus-Tags kann eine Adresse einen ganzen Run bedienen. Team hat kein Adresslimit und hebt das Anfragelimit auf 600 pro Minute.
Funktioniert der Bericht auch außerhalb von GitHub Actions?
Ja. Starte einen Run mit der API (qa.startRun() im npm-Paket, start_run() in Python), sende seine ID bei jedem Aufruf mit, schließ ihn ab und hol dir den Bericht als Markdown, um ihn dort zu posten, wo du Code reviewst.
Was lässt einen Run fehlschlagen?
Eine erwartete E-Mail, die nie kam, eine, die kam, obwohl keine kommen sollte, eine fehlgeschlagene E-Mail-Prüfung, ein vom Reporter erfasster fehlgeschlagener Test, Marketing nach einer Abmeldung, eine Person, die ein Angebot zweimal bekommt, ein Gutschein, der angenommen wurde, obwohl er abgelehnt werden sollte, oder eine Notiz, die das festhält. Mit fail-job auf true kann die Action dann auch den Job fehlschlagen lassen, selbst wenn die Tests bestanden haben.
Kann mein Coding-Agent denselben Konten-Pool nutzen?
Ja. Mit dem MCP server verbundene Agents leihen Konten aus demselben Projekt-Pool aus und geben sie zurück, sodass ein Agent und deine Testsuite nie gleichzeitig dasselbe Konto nutzen.
Weitere Funktionen
- Posteingangs-DashboardJedes Testkonto und sein Code oder Link, live
- Projekte und TeamsEins pro Kunde oder App, mit eigenen Schlüsseln und Personen
- KI-AgentenAgenten registrieren sich und holen den Code selbst
- Marketing und AngeboteIn Labs · Gutscheine, Abmeldungen und Einwilligungsregeln
- ZustellbarkeitEin Spam-Score, blockierte Dateien und zurückgewiesene E-Mails
- Chrome-ErweiterungRegistrierungsformulare ausfüllen und den Code direkt auf der Seite sehen
- MCP server und PluginsClaude, Cursor, Copilot, Codex, ChatGPT und mehr
Lass deinen nächsten Registrierungstest auf die echte E-Mail warten.
Erstelle ein kostenloses Konto, lege in Project settings einen API-Schlüssel an und füge einem Test, den du schon hast, einen Warteschritt hinzu.
Kostenloses Konto erstellenApp öffnen