Pruebas y CI
Pruebas de registro que esperan el email real.
Tus pruebas end-to-end se registran como un usuario real y luego obtienen el código o enlace en una llamada. Comprueba el propio email, da a las pruebas en paralelo sus propias cuentas y ve los emails de cada ejecución en el pull request.
Plan Free · npm, Python y REST · Playwright, Cypress, Selenium y más
Cómo funciona
Una llamada donde antes la prueba se atascaba.
Crea una dirección
Una llamada crea una dirección de prueba con una persona ficticia y una contraseña, o da el valor de cada campo de tu formulario. En CI, una dirección puede servir para toda una ejecución, con una etiqueta + por prueba.
Regístrate en tu app
Tu prueba rellena el formulario con Playwright, Cypress, Selenium o cualquier otra herramienta, y anota la hora en que lo envió.
Espera el código o enlace
La espera termina en cuanto llega el email, con solo el código o enlace. Se ignora el correo anterior al envío de la prueba.
Completa el flujo
Escribe el código o abre el enlace, y comprueba que el usuario ha iniciado sesión. Si no llegó nada, el error dice por qué, en la medida en que lo sabemos.
En tus pruebas
Unas pocas líneas en la prueba que ya tienes.
El paquete npm para Node.js, un helper de Python sin nada que instalar y la REST API para todo lo demás. Hay ejemplos completos para cada herramienta en la documentación para desarrolladores.
Playwright con el paquete npm
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 con el helper Python
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"))Qué pueden comprobar las pruebas
Más que “¿llegó el código?”.
Códigos y enlaces
Códigos de verificación y de inicio de sesión, y enlaces de verificación, de inicio de sesión mágico, de invitación y de restablecimiento, solo con el correo enviado después del envío de la prueba.
No llegó nada, o llegó uno
Demuestra que un usuario dado de baja no recibió el boletín, y detecta un registro que envía dos emails de verificación en vez de uno.
El envío y la construcción del email
SPF, DKIM y DMARC, enlaces a localhost o a http simple, un enlace que va a producción en vez de a staging, una caducidad que falta, si cabe en un teléfono, y el texto y el idioma que esperas.
Un pool de cuentas
Etiqueta las cuentas con su estado y deja que cada prueba tome una prestada. Tus propios hooks crean una cuando no hay ninguna libre, confirman su estado y la devuelven. Las pruebas en paralelo nunca comparten una.
Un informe en el pull request
Qué emails llegaron y qué tan rápido, de qué prueba vino cada uno, los códigos y enlaces, qué falló y qué cambió desde las últimas ejecuciones: emails más lentos, emails de más, pruebas inestables.
Por qué falta correo
Cuando una espera vuelve vacía, el error dice por qué, en la medida en que lo sabemos, como un proveedor de email en modo sandbox que solo envía a direcciones verificadas.
En el pull request
Los emails de cada ejecución, donde revisas el código.
Añade la action de Proxy Mail QA antes de tus pruebas. El paquete npm y el helper de Python añaden a la ejecución lo que ven, y la action publica el informe cuando termina el trabajo, haya pasado o no. Con el fixture y el reporter de Playwright, o los hooks de pytest, también indica de qué prueba vino cada email y qué pruebas fallaron.
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 }}Hecho para CI
Seguro para ejecutar en cada push.
-
Su propia clave
Da a CI su propio proyecto o clave, guardada en los secretos de tu sistema de CI. Revocarla no afecta a nada más.
-
Una dirección por ejecución
El correo a nombre+loquesea@ llega a nombre@, y una espera en una dirección etiquetada solo encuentra su propio correo, así que un pipeline con mucha actividad se mantiene muy por debajo de los límites diarios.
-
Workers en paralelo
Una espera es una sola solicitud, dure lo que dure. Las claves hacen 60 solicitudes por minuto en Free y 600 en Team.
-
El informe no guarda texto de emails
Una ejecución guarda las direcciones, los códigos, los tiempos, los resultados de las comprobaciones, los nombres y errores de las pruebas fallidas, y el sitio y la ruta de cada enlace, con las partes que parecen tokens ocultas. Nunca el texto ni el asunto de un email, ni la query de un enlace. Las ejecuciones se guardan 90 días.
-
Los forks no reciben secretos
En un pull request desde un fork, la action avisa y no inicia ninguna ejecución, así tu clave nunca llega a código que no has revisado.
-
Solo sitios de prueba
Proxy Mail QA es para versiones de desarrollo, staging, QA, vista previa y locales de apps que creas o que puedes probar, nunca para las de producción.
FAQ
Preguntas
¿Pueden las pruebas comprobar cupones y bajas?
Sí. Espera un cupón con su descuento y fecha de fin, registra qué hizo el checkout con él, comprueba que una persona no pueda reclamar una oferta dos veces y marca una dirección como dada de baja para que el marketing posterior falle. Consulta emails de marketing y ofertas.
¿Con qué herramientas de pruebas funciona?
Con cualquiera que pueda hacer una solicitud HTTP. El paquete npm cubre test runners de Node.js como Playwright, Cypress y Puppeteer, el helper de Python cubre pytest con Selenium o Playwright, y pequeños helpers para XCUITest, Espresso, Flutter, Maestro, Detox y Appium comprueban emails, usan el pool de cuentas y también añaden al informe de la ejecución. Todo lo demás usa la REST API.
¿Necesito el plan Team?
No. El paquete npm, el helper de Python, la REST API, la Action de GitHub, las ejecuciones y el pool de cuentas están en todos los planes. Las claves de Free hacen 60 solicitudes por minuto, una cuenta Free tiene 500 direcciones en total (hasta 50 al día), y las etiquetas + permiten que una dirección sirva para toda una ejecución. Team no tiene límite de direcciones y sube el límite de solicitudes a 600 por minuto.
¿Funciona el informe fuera de GitHub Actions?
Sí. Inicia una ejecución con la API (qa.startRun() en el paquete npm, start_run() en Python), envía su id con cada llamada, termínala y obtén el informe como Markdown para publicarlo donde revises el código.
¿Qué hace fallar una ejecución?
Un email que una prueba esperó y nunca llegó, uno que llegó cuando no debía, una comprobación de email fallida, una prueba fallida que registró el reporter, marketing después de darse de baja, una persona que recibe una oferta dos veces, un cupón aceptado cuando no debería, o una nota que lo indique. La action también puede hacer fallar el trabajo en ese caso, aunque las pruebas hayan pasado, con fail-job en true.
¿Puede mi agente de programación usar el mismo pool de cuentas?
Sí. Los agentes conectados al MCP server reservan y devuelven cuentas del pool del mismo proyecto, así que un agente y tu suite de pruebas nunca usan la misma cuenta a la vez.
Más funciones
- Panel de bandejas de entradaCada cuenta de prueba y su código o enlace, en vivo
- Proyectos y equiposUno por cliente o app, con sus propias claves y personas
- Agentes de IALos agentes se registran y obtienen el código por sí mismos
- Marketing y ofertasEn Labs · cupones, bajas y normas de consentimiento
- EntregabilidadPuntuación de spam, archivos bloqueados y correo devuelto
- Extensión para ChromeRellena formularios de registro y ve el código en la página
- MCP server y pluginsClaude, Cursor, Copilot, Codex, ChatGPT y más
Haz que tu próxima prueba de registro espere el email real.
Crea una cuenta gratis, crea una clave de API en Project settings y añade una espera a una prueba que ya tengas.
Crear una cuenta gratuitaAbrir la aplicación