This document lists comprehensive test cases to verify your Distributed Share Market System (DSMS) functionality, covering both **normal operations** and **crash scenarios** (process crash). The DSMS includes:
We also show **visual diagrams** depicting where a crash might occur and how the system recovers.
Below is a listing of core admin and buyer operations, covering typical edge cases. These assume **all replicas are running** and no process crashes occur.
| Test Case ID | Operation | Scenario | Expected Result |
|---|---|---|---|
| T-Admin-01 | addShare | Admin adds a new share with valid inputs | Share is successfully created with correct capacity; success message returned. |
| T-Admin-02 | addShare | Admin attempts to add an existing shareID | Operation fails with a message “Share already exists.” No new share is created. |
| T-Admin-03 | removeShare | Admin removes an existing share | Share is removed from the server. Future list or purchase references should fail for that share. |
| T-Admin-04 | removeShare | Admin attempts to remove a non-existent shareID | Operation returns “Share not found” or similar message. |
| T-Admin-05 | listShareAvailability | Admin requests availability for a valid shareType (EQUITY, BONUS, or DIVIDEND) | All known shares of that type are returned with capacities from each server city. No error. |
| T-Buyer-01 | purchaseShare | Buyer purchases a share with sufficient capacity available | Buyer's purchase is recorded, capacity is reduced accordingly. Successful response. |
| T-Buyer-02 | purchaseShare | Buyer tries to purchase more than capacity, or shareID doesn’t exist | Purchase fails or partial is allocated (depending on logic); an error or partial success message is returned. |
| T-Buyer-03 | getShares | Buyer requests their existing holdings | All owned shares and quantities from all servers are returned. |
| T-Buyer-04 | sellShare | Buyer tries to sell shares they own, less than or equal to the purchased quantity | Operation succeeds, capacity goes up on that share. Buyer’s holdings are decreased accordingly. |
| T-Buyer-05 | sellShare | Buyer tries to sell a share they do not own | Operation fails with error message (e.g., “You do not own this share.”). |
| T-Buyer-06 | swapShares | Buyer attempts to swap oldShare for newShare with enough capacity in newShare | Old share is removed from the buyer's holdings, new share is allocated. Successful swap message returned. |
| T-Buyer-07 | swapShares | Buyer attempts to swap but newShare lacks capacity | Swap fails; old share is returned to the buyer’s holdings. Clear error message. |
**Note**: For cross-city purchases (if you have that limit of 3 shares across different cities), add an additional test verifying the limit is enforced.
In the following scenarios, at least one **replica** is forcibly terminated during or right after a request is broadcast by the Sequencer. We assume your DSMS is in crash-failure tolerance mode (i.e., not the software-fault mode). The system should continue to operate with the remaining replicas.
| Test Case ID | Crash Point | Operation | Expected System Behavior |
|---|---|---|---|
| Crash-01 | After Sequencer sends an “addShare” request to all replicas, Replica B is killed before responding |
addShare |
FE receives 2 responses (Replica A and Replica C). FE times out waiting for B, suspects crash. FE returns success if A and C results match. RM(B) restarts or replaces B. System remains consistent with the new share added. |
| Crash-02 | During “removeShare” broadcast, Replica A’s process is terminated in mid-execution | removeShare |
FE gets responses from B and C. A never responds => crash suspicion => RMs confirm. The share is removed on B and C. Replica A is later restarted or replaced. Once A is back, it can catch up on missed requests. |
| Crash-03 | Replica C is killed after sending an incorrect partial result for “purchaseShare” (if that partial result arrives, it might be irrelevant in crash mode, but let's say we never trust incomplete data) | purchaseShare |
FE compares responses from A, B, C. If C is killed mid-flight, FE might get no final ack from C. A and B match => FE proceeds with that result. FE flags C as crashed. RM(C) restarts C. The final system state is consistent per A and B. |
| Crash-04 | Replica B is killed before any response for “swapShares” | swapShares |
FE collects responses from A and C. If they match, the swap is successful. B is restarted later by RM(B). The buyer’s holdings reflect the swapped share on A and C. B syncs after restart. |
| Crash-05 | Replica A is killed mid “sellShare” operation. FE times out on A’s response | sellShare |
FE obtains matching results from B, C, concludes the sale. A is flagged for crash; RM(A) restarts it. Overall capacity is incremented as B and C performed the sale. |
In each crash case, once the Replica Manager detects or is notified of the crash, it spins up a new instance (or restarts) so the system returns to having 3 replicas. The FE can respond to requests as soon as it has at least 2 matching responses from the healthy replicas.
Below are two sample sequence diagrams illustrating crash scenarios and the subsequent recovery. The first focuses on a crash during an admin operation (e.g., addShare), the second focuses on a buyer operation (e.g., purchaseShare).
The test cases above (normal operations + crash scenarios) will help you verify correctness, robustness, and recovery in your actively replicated DSMS:
Together, these tests ensure the DSMS achieves the **high availability** goal under a single crash failure.