Test expiry,
not just email delivery

One successfully delivered email tests only the middle of the process

Copying an address, sending an email, and seeing a verification code only proves that delivery worked once, at that moment. A disposable inbox also promises that the old address will stop working when its time is up, and that its emails can no longer be read with the old credentials. New arrivals shouldn’t interrupt the email you’re reading, either.

So disposable inbox testing should cover the full lifecycle, not just a screenshot showing “one email received.” Start with the temporary inbox, then test using an email account you control as the sender and fictional content. Don’t create real accounts just to generate samples, and never use bank verification codes, order details, or customer information as test data.

Define the boundaries first: when the address, email, and browser credentials expire

Start by separating three things. The address determines where incoming email goes, the email is content stored on the server, and browser credentials determine who can read that inbox. They aren’t the same: text still visible on a page doesn’t mean the address can still receive mail, and credentials stored locally don’t mean the server still accepts them.

New addresses on the FadeInbox homepage are valid for 3 hours by default. One successful extension adds 3 hours. Changing the address creates a new 3-hour address and destroys the old inbox. Use the server response and the page countdown to determine the actual expiry time.Expiry planning explains the rules; your test record should also note what you observed this time.

If a new address is generated automatically after expiry, record the old and new inbox tests separately. Normal delivery to the new inbox doesn’t prove the old one stopped working. A temporary inbox doesn’t mean “destroyed as soon as you read it”; in this test, destruction means the validity period has ended or deletion has been explicitly requested.

Prepare repeatable samples: a unique test ID and plain-text and HTML emails

Give this test run a non-personal ID, such as FX-261014-A. Use these subject lines, in order: FX-261014-A / 01 / TEXT and FX-261014-A / 02 / HTML. Use the ID to tie your records together. Don’t include the full recipient address or access credentials.

Give each email a different purpose

• Plain-text email: Include a few ordered lines of text, one long word, and a fictional six-digit number. Check line breaks, wrapping on narrow screens, and copy-and-paste.
• HTML email: Use a self-made header, title, verification-code block, and sufficiently long body, along with a plain-text alternative.
• For both: Use a reserved example domain. Don’t include real login links, tracking pixels, or external data-collection forms.

When checking how a verification email is displayed, make sure the digits aren’t truncated, the body and background are readable, and the content doesn’t overflow horizontally on narrow screens. Isolated HTML shouldn’t inherit the inbox’s button styles. Blocked external images aren’t automatically a failure; what matters is that the essential information remains readable.

The WhatsApp and LinkedIn sample emails on the homepage illustrate the interface; they don’t prove that email delivery works. For acceptance testing, send your own real test emails. If one doesn’t arrive, check delivery diagnostics first. Don’t confuse delays with duplicate deliveries by repeatedly resending the email.

Countdown boundaries: what to check in the foreground, in the background, and after reopening the page

Record the expiry time after creating the inbox, then watch the countdown. In the foreground, it should update every second, not jump only when a poll runs. Near expiry, record three moments: before expiry, after crossing the expiry time, and after the status updates. The interface may take a short time to refresh, but it shouldn’t show the inbox as available indefinitely.

Backgrounding a tab doesn’t pause the inbox’s lifetime

Leave the tab in the background for a few minutes, then return. Browsers may throttle timers, so don’t expect code to run every second in the background. Check that the countdown corrects itself based on the actual expiry time when you return. It shouldn’t simply continue from the number of seconds shown before you left, making the address appear to last longer.

Reopen the page to check restoration, not a “fresh start”

Close and reopen the page normally in the same browser. A valid inbox should keep its original expiry time; it shouldn’t reset to 3 hours without reason. Incognito windows, cleared site data, and another device are different conditions. Test them separately rather than reporting them as restoration failures.

Don’t change your computer’s clock to simulate server-side expiry. If you don’t have an approved short-duration test environment, plan to wait it out. You can test other cases first, but you still need to cross the actual expiry boundary.

Extension and address change are different actions: test the lifetime and old-address boundaries separately

An extension should keep the same address and existing emails, changing only the expiry time. Note the expiry time before you act, click once, wait for confirmation, then check that the new expiry time is about 3 hours later. Don’t simply subtract the two displayed countdowns without accounting for the time spent on the action.

Changing the address does the opposite: a new address appears with a new expiry period, and the old inbox and its emails are destroyed. Check the extension first, then change the address. Confirm that the new address starts a fresh 3-hour window rather than inheriting the old inbox’s extended lifetime.

• Extension succeeds: the address stays the same, old emails remain readable, the expiry time moves later, and the page confirms success.
• Address change succeeds: the address changes, old emails disappear from the list, and neither the selection nor message carries over to the new inbox.
• Action fails: don’t report success or discard a usable old address before a valid new inbox is available.

Don’t click repeatedly when the network is slow. If the interface stays on “Processing,” wait for the request to finish and check the result. A bounce from the sender isn’t enough to prove the old address is invalid: the sender may queue or retry the message, or may not provide bounce notifications.

Polling shouldn’t interrupt reading: check selection and scroll position with two test emails

Open the longer HTML test email and scroll to the middle of the body. Note a line of text. Then send a second email from your own account and wait for the new row to appear. The list can update, but the current subject, selected row, message, and scroll position should stay the same.

Wait through at least two polling cycles, then manually switch to the other email. If the view keeps jumping back to the first email, the body briefly flashes, or the scroll position resets every few seconds, the reading area is probably being rebuilt when the list refreshes. Marking an email as “read” shouldn’t trigger an automatic switch, either.

Repeat the test on a phone

Opening a real email should bring up a separate reading view, with the back and delete actions always accessible and the background unable to scroll. A new arrival can update the list, but shouldn’t open the reading view automatically. When you return to the list, the email you were reading should still be selected. Automatically selecting an email and opening one at the user’s request are different events.

Finally, delete the current email. Check whether the view moves to another email or shows a clear empty state. Once the list is empty, both the list and details should have a heading and description, not a leftover old email header.

Old message still visible after expiry? Distinguish interface cache from server access

If old text is still visible at expiry, don’t immediately conclude that “the server didn’t delete it.” The browser may still have the message loaded in memory. Alternatively, the app may still be able to retrieve the old details. The first is a display-cleanup issue; the second concerns access or retention boundaries. Record both, but note that they’re different kinds of evidence.

1. Note the page state after expiry: is the old address still marked as available, and has the old message been removed?
2. Refresh the page or reopen the old email to check whether it triggers a new request for details, rather than continuing to show content that was already loaded.
3. If you’re comfortable using developer tools, check the request status and response content in your own test inbox. Hide query parameters and authentication details before taking screenshots.

A disconnected network, timeout, or single failed request doesn’t prove that destruction succeeded. Confirm that the server explicitly denies access to the old inbox or returns the corresponding expired status. Invalidated old credentials only show that the inbox can’t be retrieved through that particular access path. Front-end testing alone can’t prove that backups, logs, and all stored copies have been physically erased.

If the page has switched to a new inbox, record checks on the old one separately. Don’t replace the old credentials with the new ones and use “I can’t find the old email” as your only evidence. Data handling is governed by the Privacy Policy.

Record test results as acceptance criteria, not as a collection of screenshots containing secrets

A good record lets a colleague reproduce the same steps without giving them access to your inbox. Keep the test ID, browser version, device width, timestamps with time zone, steps, expected results, and observations. Use a code in place of the address, and use only fictional verification codes.

Task: FX-261014-A
Environment: Browser version / OS / viewport width
Test case: Receive a second email while reading a long email
Steps: Open 02 → scroll to the paragraph marker → send 01 → wait through two polling cycles
Expected: New row appears; current email, selection, and scroll position stay the same
Actual: Fill in after testing; don’t assume “pass”
Evidence: Redacted screenshot ID / observation time and time zone
Result: Pass / Fail / Needs review

Don’t share a complete network export file. It may contain temporary inbox tokens, account tokens, email content, or links to downloadable attachments. If you need to share diagnostic material, redact it according to your team’s guidelines and limit access. If you’re unsure, share the steps and time of the error instead of the raw request.

“Needs review” is a valid result. For example, note if the sender hasn’t delivered the email yet, the network went down during testing, or the computer was asleep when the temporary inbox expired. Don’t force a “pass” just to make the table look complete.

Clean up after testing—and what a temporary inbox can’t prove

Delete the samples you sent, downloaded attachments, and local diagnostic files. Check whether testing accidentally created an external account or subscription. Store any acceptance records separately from inbox credentials. Destroying the address won’t delete copies in your sent folder or clear data held by external platforms.

These test cases can check email delivery, reading, and expiry boundaries. They can’t prove that every sender accepts temporary addresses, emails are never delayed, content is completely anonymous, or real accounts can always be recovered. Use an email account you control directly for important accounts. For ongoing test notifications, consider a email forwarding alias—though it still isn’t a permanent backup.

To choose an address, start by comparing disposable email addresses and aliases. The most valuable things to keep at the end of testing are reproducible boundaries and clear conclusions—not an old email that can still be opened.