nick/nick-doc
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: add notification and concurrency test procedures

Browse Source
This commit is contained in:
Siavash Sameni
2026-06-06 10:57:44 +04:00
parent 9267961909
commit bee91dd01f
6 changed files with 552 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
11 - Testing/Escrow Marketplace E2E Procedure.md
View File

@@ -18,6 +18,7 @@ or scanner changes.
- BSC Testnet wallet has enough tBNB for gas and enough canonical tUSDT.
- Backend/scanner chain 97 registry points to `0x109F54Dab34426D5477986b0460aE5dFBA65f022`.
- Local wallet private key or mnemonic is stored only in ignored `.env`.
- Notification checks are enabled in the runner. See [[Notification Assertion Procedure]].
## Actors
@@ -31,20 +32,28 @@ or scanner changes.
1. Generate a run id.
2. Admin creates one buyer and at least two sellers.
3. Buyer creates purchase request with a min/max USDT budget.
4. Sellers submit bids inside the budget range.
5. Randomize or vary:
3. Assert initial notification baselines for buyer and sellers.
4. Buyer creates purchase request with a min/max USDT budget.
5. Assert purchase-request notifications for expected sellers.
6. Sellers submit bids inside the budget range.
7. After each seller bid, assert offer notifications for the buyer.
8. Randomize or vary:
- bid amount,
- delivery timing,
- seller note,
- delivery method.
6. Buyer selects a bid.
7. Backend creates scanner payment intent.
8. Buyer pays with BSC Testnet tUSDT.
9. Scanner confirms the payment.
10. Seller marks delivery.
11. Buyer confirms delivery.
12. Record current block: flow pauses before automated release policy.
9. Buyer selects a bid.
10. Assert offer-accepted notification for selected seller and offer-rejected/updated notifications for non-selected sellers when implemented.
11. Backend creates scanner payment intent.
12. Assert payment-pending or payment-started notification where implemented; if missing, record as notification coverage gap.
13. Buyer pays with BSC Testnet tUSDT.
14. Scanner confirms the payment.
15. Assert payment-confirmed notifications for buyer and selected seller.
16. Seller marks delivery.
17. Assert delivery notification for buyer.
18. Buyer confirms delivery.
19. Assert delivery-confirmed notification for selected seller and buyer status notification if implemented.
20. Record current block: flow pauses before automated release policy.
## Expected State Transitions
@@ -58,6 +67,40 @@ or scanner changes.
| Seller delivers | `delivery` | escrow remains held |
| Buyer confirms | `delivered`, `deliveryConfirmed=true` | release policy not automatic yet |
## Notification Assertions After Every Step
Notification verification is mandatory after every state-changing step. A step
is not complete until the test runner has either:
1. observed the expected notification for every recipient; or
2. recorded a known coverage gap with route/action, expected recipient, and linked issue/backlog item.
Use [[Notification Assertion Procedure]] for the exact API/socket checks.
| Step | Expected recipients | Required notification assertion |
|---|---|---|
| Baseline after user creation | buyer, every seller | Capture unread count and latest notification id for each actor before business mutations. |
| Buyer creates request | eligible sellers | Sellers receive a request/new-opportunity notification, or the gap is recorded. |
| Seller submits bid | buyer | Buyer receives a new-offer notification with `relatedId` or action URL pointing to the request/offer. |
| Buyer selects bid | selected seller; non-selected sellers if rejection notices are implemented | Selected seller receives acceptance notification. Non-selected sellers receive rejection/update notification where supported. |
| Payment intent created | buyer | Buyer receives payment-started/pending notification where supported. Missing `pending_payment` coverage is a known notification gap and must be recorded. |
| Scanner confirms payment | buyer, selected seller | Buyer and seller receive payment-confirmed/funded notification. |
| Seller marks delivery | buyer | Buyer receives delivery/proof submitted notification. |
| Buyer confirms delivery | selected seller; buyer if status-change notices are implemented | Seller receives delivery-confirmed notification. |
| Dispute raised, when added | buyer, seller, admin/mediator | All parties receive dispute-created/hold notification. |
| Release/refund, when added | buyer, seller, admin | Funds movement notification is persisted and pushed. |
Minimum notification evidence per assertion:
| Evidence | Source |
|---|---|
| unread count before and after | `GET /api/notifications/unread-count` |
| latest notification payload | `GET /api/notifications?limit=5` |
| recipient id/email | authenticated actor profile or test user record |
| notification category/type/title/actionUrl | notification payload |
| socket event, if runner supports it | `new-notification` on `user-<userId>` |
| elapsed time from action to notification visibility | runner timestamp |
## Buyer Request Template
Use unique values so live data can be filtered later:
@@ -142,6 +185,8 @@ Minimum assertions per round:
| Seller delivery returns HTTP 200 | yes |
| Buyer confirm delivery returns HTTP 200 | yes |
| Final request status is `delivered` | yes |
| Notification assertion executed after each state-changing step | yes |
| Notification gaps are recorded with expected recipient and route/action | yes |
## Reference Execution - 2026-06-06
@@ -204,4 +249,3 @@ Release policy is not complete:
- dispute-to-release/refund automation is not complete.
Use [[Testing Expansion Backlog]] before extending this scenario into fund release.