Test cases for email compose (Gmail-style)
Updated 2026-11-13 · 6 min read
These 30 cases use explicit test fixtures and checkable outcomes. Cover normal behavior, boundaries, recovery, security and usability, then adapt the requirements to your product.
How to answer in an interview
Ask about recipient limits, draft persistence, attachment limits, offline sending and any undo window. Separate composing, server acceptance and final delivery. Then trace a draft through edits, send and a lost acknowledgement; those transitions expose more than checking the Send button alone.
Scope and test data
These 30 cases describe a fictional Gmail-style composer, not a verified Gmail release. It has To, Cc, Bcc, subject, rich text, attachments, server-saved drafts and a configurable undo delay. Use [email protected], [email protected] and [email protected] in an isolated mail sink only. Gmail documentation is background for recipient and undo concepts; product limits below must come from your own specification.
Before execution, record recipient limit R, attachment limit B bytes, subject limit S, draft-save target and undo window W. This example permits a blank subject only after confirmation, rejects empty recipient sets, deduplicates identical recipients and prevents sending while uploads are incomplete. Keep the sending system disconnected from real recipients.
These are proposed manual test cases, not an execution report. Run security and load checks only in an authorised isolated environment. Record agreed limits before execution; a case without its required limit is not ready to pass or fail.
Recipients and composition
| ID | Category | Test case | Expected result |
|---|---|---|---|
| E01 | Functional | Compose to [email protected] and send to the test sink | One message has the exact intended subject, body and recipient |
| E02 | Functional | Add To, Cc and Bcc recipients and inspect each received copy | Delivery reaches all intended sink addresses; To and Cc copies do not expose Bcc recipients |
| E03 | Negative | Click Send without any recipient | Recipient error appears; draft remains unsent |
| E04 | Negative | Enter asha@ and attempt to send | Invalid recipient is identified and send is blocked |
| E05 | Functional | Paste several supported address tokens | Every parsed token is visible for review; none is silently dropped |
| E06 | Functional | Add the same exact address twice | One effective recipient remains under the deduplication contract |
| E07 | Boundary | Add R recipients, then R plus one | R is accepted; the extra recipient triggers a limit error before send |
| E08 | Functional | Change the sender among authorised identities | Selected sender is used in the sink message and Sent copy |
| E09 | Functional | Send Hindi text, emoji and multiline content | Recipient copy preserves text and line breaks |
| E10 | Negative | Send a blank subject, cancel warning, then confirm | Cancel retains draft; confirmation sends one message with blank subject |
Drafts and attachments
| ID | Category | Test case | Expected result |
|---|---|---|---|
| E11 | Functional | Edit body and wait for confirmed draft save, then reload | Last acknowledged draft content and recipients are restored |
| E12 | Negative | Disconnect while draft saving is pending | Unsaved state is visible; the UI does not claim server persistence |
| E13 | Functional | Open two different drafts and edit both | Each draft retains only its own recipients, body and attachments |
| E14 | Functional | Discard a saved draft and reopen the drafts list | Discarded draft is absent; an old save response cannot resurrect it |
| E15 | Boundary | Enter subjects of S and S plus one characters | S is retained; excess is rejected with an explanation rather than silently lost |
| E16 | Functional | Attach a permitted small file and send | Received filename and file contents match the original test file |
| E17 | Boundary | Attach permitted files totalling B and B plus one bytes | B passes; excess is blocked using the documented size accounting rule |
| E18 | Negative | Choose a forbidden file type | Upload or send is blocked with the applicable file rule |
| E19 | Negative | Attempt Send while an attachment upload is incomplete | Send is blocked or waits visibly; no attachment-free message is sent accidentally |
| E20 | Functional | Remove an uploaded attachment before sending | Neither recipient copy nor Sent copy contains that attachment |
Send lifecycle and safety
| ID | Category | Test case | Expected result |
|---|---|---|---|
| E21 | Functional | Double-click Send during a slow acknowledgement | One logical message appears in Sent and at the sink |
| E22 | Negative | Lose the acknowledgement after acceptance and retry | The existing send is reconciled; no second logical message is created |
| E23 | Functional | Use Undo before W expires | Pending send is cancelled and the editable draft returns; sink receives nothing |
| E24 | Boundary | Try Undo after W expires | UI no longer promises cancellation; accepted delivery is not represented as recalled |
| E25 | Negative | Expire the session before Send | Reauthentication is required; content is retained according to the draft policy |
| E26 | Security | Modify the sender to an unauthorised address | Server rejects the impersonation attempt |
| E27 | Security | Paste active markup into rich text and inspect all rendered copies | Unsafe active content cannot execute in draft, Sent or recipient views |
| E28 | UI | Use keyboard and screen reader for recipient chips, attachments and errors | Controls have meaningful names; chips can be removed and failures located |
| E29 | Compatibility | Compose and reopen the same draft on supported browser and mobile clients | Saved recipients, text and attachments agree across clients |
| E30 | Performance | Save and send the largest permitted draft under the agreed workload | Save and acceptance meet their recorded budgets; no duplicate send occurs |
Avoid claiming delivery from the wrong evidence
Correlate the draft ID, accepted message ID, Sent entry and sink receipt. A server accepting a message is not proof that another provider delivered it. Test provider rejection and later bounces separately if the product owns that workflow.
An interviewer may ask whether Undo Send recalls mail already read. Describe the configured cancellation window and its boundary; do not promise recall. Google documents Gmail's undo feature, but these cases deliberately avoid adopting its current UI or limits as universal requirements.
Downloads
Quick answers
Can these cases be run against real Gmail accounts?
They are a design checklist for an isolated test system. Do not send messages to real people; map the limits and behavior to the product under test.
What is the highest-risk compose scenario?
A timeout after server acceptance followed by retry can create duplicate messages. Check the message identity and sink receipts, not just the toast.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.