gecici.email

PRACTICAL GUIDES ·

Email verification testing with Playwright: a runnable Chromium example

An email verification test should do more than wait for a code. This example drives a local form in real Chromium, rejects a wrong code, verifies the correct one and rejects replay. It creates one gecici.email test inbox and deletes it when finished.

Open a temporary inboxBrowse all guides

What this test actually exercises

The browser, local Python application and hosted gecici.email API are real. A fictional message is inserted into the test's own inbox through authenticated simulation. The run does not exercise external SMTP, a third-party signup or an LLM. Replace simulation with your application's actual mail sender when adapting the pattern.

Download three files into one folder

Review the sources first. In a separate test directory with Node.js, npm and a working python3 command, run the following. The test creates its own temporary hosted inbox; it does not read your existing inboxes.

npm init -y
npm install --save-dev @playwright/test@1.65.0
npx playwright install chromium
npx playwright test --config=playwright.config.cjs

The configuration starts the application on 127.0.0.1:8797 and shuts it down afterwards. It refuses to reuse a process already on that port. Keep this teaching server local.

Five distinct checks

  1. message_simulated · 201: the test inbox and fictional message exist.
  2. wrong_code · 400: the application rejects an incorrect code.
  3. verified · 200: the code read from the inbox verifies the application challenge.
  4. already_used · 409: the used challenge rejects replay.
  5. cleaned · 200: the inbox is deleted from the test's finally block.

This Chromium flow passed on 14 November 2026. The inbox address and token stay in the Python process and are not written to the test output. Trace, video and automatic failure screenshots are disabled. The result is not an SMTP delivery benchmark.

Adapt it to your application

Submit only the address to your signup form; keep the inbox token in the test runner. Trigger your application's sender, wait for the matching message with a deadline, enter the code and assert the actual verified account state. Create a separate inbox for each parallel test.

The fixture's /read endpoint is a teaching convenience. Do not expose an endpoint that returns a user's code in production authentication. A real test runner should retrieve the message directly through the authenticated mailbox API.

The local application challenge lasts 120 seconds and permits five attempts. That is separate from the inbox's default 60-minute lifetime.

Diagnose a failed run

start_failed_retry_cleanup indicates creation or simulation failed. For not_arrived, check the message insertion result. If cleanup fails, retry while the local server is still running; normal shutdown also attempts deletion. A forcibly killed process cannot run cleanup, so the inbox may remain until expiry.

Playwright's API testing documentation explains combining browser sessions and API requests. Use the REST reference for mailbox endpoints, or the manual local-form guide to explore the same fixture without automation.