Test cases for a chat app (WhatsApp-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 whether the scope includes direct chats, groups, multiple devices, offline queues and read receipts. Define sent, delivered and read before writing assertions. Then follow one message from a local pending state through reconnect and receiver acknowledgement.
Scope and test data
These 30 cases target a fictional WhatsApp-style application, not WhatsApp itself. Use synthetic users Asha Test, Ravi Test and Neha Test on isolated accounts A, B and C. The example supports direct text, attachments, groups, read receipts and delete-for-everyone within a configured window D. Set text limit M and attachment limit B before testing.
For this fixture, sent means server accepted, delivered means a recipient client acknowledged receipt, and read means the permitted read signal was received. Group aggregation, blocking semantics and retention are explicit product decisions. WebSocket is a bidirectional transport; its existence alone does not establish these application-level delivery states or end-to-end encryption.
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.
Messages and history
| ID | Category | Test case | Expected result |
|---|---|---|---|
| H01 | Functional | A sends text to online B | B receives one message with the same body and sender; A sees server acceptance |
| H02 | Functional | B replies to A | Reply appears in the correct direct conversation on both clients |
| H03 | Functional | Send Hindi text, emoji and line breaks | Both clients preserve content without replacement characters |
| H04 | Negative | Submit an empty or whitespace-only message | No message is created under the example text policy |
| H05 | Boundary | Send M and M plus one characters | M is accepted; excess is rejected with the configured limit |
| H06 | Functional | Send three numbered messages rapidly from one client | Recipient shows the agreed server sequence without gaps or duplicates |
| H07 | Functional | Reply to a specific earlier message | Quote links to the intended message, even when intervening messages arrive |
| H08 | Functional | Load older history while new messages arrive | Older and newer records join without duplicated IDs or scroll jumps away from the reading position |
| H09 | Functional | Search a conversation for a seeded phrase | Only authorised matching messages appear; selecting a result opens its context |
| H10 | Functional | Restart after confirmed message persistence | Acknowledged history remains available according to retention policy |
Offline, receipts and group state
| ID | Category | Test case | Expected result |
|---|---|---|---|
| H11 | Functional | A sends while offline, then reconnects | Pending state changes to accepted only after acknowledgement; B receives one copy |
| H12 | Negative | Drop acknowledgement after server storage and retry | Same logical message is reconciled without a second receiver copy |
| H13 | Functional | Keep B offline after server acceptance | A does not see delivered or read until their defined acknowledgement events occur |
| H14 | Functional | B receives without opening the conversation | Delivered appears; read does not appear prematurely |
| H15 | Functional | B opens the conversation with receipts enabled | A sees read for the messages actually covered by B's read position |
| H16 | Functional | B disables read receipts under the supported privacy option | Subsequent read activity is not exposed beyond the documented exception policy |
| H17 | Functional | Open A's account on a second supported device | History and pending operations reconcile without duplicating sent messages |
| H18 | Functional | Add C to a group with restricted pre-join history | C sees only history allowed by the group's membership policy |
| H19 | Security | Remove C from the group and request new messages as C | Post-removal messages and attachments are denied by the server |
| H20 | Functional | Delete a message for everyone before D expires | Eligible clients show the agreed deletion marker; a later sync does not restore the body |
Media, privacy and quality attributes
| ID | Category | Test case | Expected result |
|---|---|---|---|
| H21 | Boundary | Attempt delete-for-everyone just after D | Action is rejected or unavailable; UI does not falsely show a global deletion |
| H22 | Functional | Upload an allowed image and download it as B | Image belongs to the intended conversation and matches the test file |
| H23 | Boundary | Upload B-byte and B-plus-one-byte attachments | Boundary file passes; excess gets a clear size error |
| H24 | Negative | Interrupt an attachment upload and retry | One completed attachment is linked; partial upload is not shown as downloadable |
| H25 | Security | C requests the direct conversation or attachment URL for A and B | Access is denied even when C knows the resource ID |
| H26 | Security | Block B from A, then attempt a new message from B | New delivery follows the documented block policy without revealing A's private status |
| H27 | Security | Send markup-like message text | Neither message bubbles nor previews execute active content |
| H28 | UI | Use screen reader and enlarged text in a long conversation | Sender, body and delivery state are distinguishable; composer remains reachable |
| H29 | Compatibility | Repeat offline send on each supported mobile and web client | One message and consistent state transitions result on every client |
| H30 | Performance | Run the agreed concurrent-chat workload and a long history | Send-to-receive and history-load times meet recorded targets; failures and dropped IDs are counted |
Prove the transition, not the icon colour
Record the message ID, sender acceptance time, receiver acknowledgement and visible state on both devices. Device clocks may disagree, so use a common measurement clock when calculating latency. An icon is only useful evidence when its meaning is documented.
If asked about encryption, separate content visibility tests from cryptographic assurance. Reading encrypted network traffic or seeing a lock icon cannot establish the full security of an end-to-end encryption implementation. These cases do not make that claim.
Downloads
Quick answers
Does sent mean delivered?
Not in this fixture. Sent is server acceptance; delivered requires a receiver acknowledgement. Agree on the definitions used by the real product.
How do I test duplicates after reconnect?
Interrupt the connection after storage but before acknowledgement, reconnect and retry, then compare stable message IDs and receiver history.
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.