An Email-Test Contract for CI/CD Jobs

An automated email test needs more than an inbox address. It needs a contract describing which message belongs to the run, how long to wait and what evidence to retain when the test fails.

Give every run a correlation record

Store a test-run identifier, synthetic recipient, trigger time and expected message purpose. Where your application supports it, include a non-sensitive correlation marker in the test message. Match using more than the subject alone: an old message with the same subject can otherwise make a broken run appear successful.

Wait within an explicit budget

create test context
trigger the application action
until the test deadline:
    read messages using the provider's documented API
    accept only a message matching this run
    wait using bounded backoff if no match exists
report matched, timed out, or provider error

This is pseudocode, not a CleanTempMail API example. Use the current API documentation for authentication, endpoints and request limits. Honor retry instructions and cancel remaining work when the job ends.

Assert behavior after receipt

In a test environment you control, confirm that the verification action produces the intended account state. Receiving a message alone is not proof that its link works. Keep authentication tokens and message bodies out of ordinary CI output.

Make failures diagnosable

Distinguish application-send failure, no matching message before the deadline, provider unavailability and assertion failure. Retain sanitized timestamps and identifiers, then remove synthetic accounts and mail artifacts according to the team's test-retention policy.