An email adapter keeps test cases from depending on one provider's response format. It should expose a small contract while preserving enough information to diagnose failures.
Define four operations
- Prepare: establish an allowed synthetic recipient and record the test context.
- Wait: find a message matching the recipient, purpose and request window within a deadline.
- Read: obtain the content needed for the assertion without logging secrets.
- Clean up: remove test artifacts where supported and record any incomplete cleanup.
Return distinct outcomes
| Outcome | Meaning |
|---|---|
| Matched | A message satisfies this test's correlation rules. |
| Timed out | No matching message was observed before the deadline. |
| Access rejected | The credential or inbox access could not be validated. |
| Provider unavailable | The mailbox service could not complete the operation. |
Test the adapter independently
Use fixtures to check pagination, empty results, retries, malformed responses and cancellation. Keep a small, rate-limited live integration check for behavior that fixtures cannot establish. Follow the provider's current API contract rather than scraping the inbox UI.
Keep product assertions above the adapter
The application test should decide whether a welcome message has the correct destination or whether a verification flow changes the intended state. The adapter should not silently declare those business outcomes successful merely because an email arrived.
Consult the current CleanTempMail API documentation before implementing its adapter, including authentication and usage limits.