67244223ec
Add 10 - Services/ docs for all sub-projects: backend, frontend, scanner, deployment (new), update amanat-assist. Update Scanner Architecture, Telegram Mini App flow, and Activity Log. Add payment safety edge cases.
213 lines
8.1 KiB
Markdown
213 lines
8.1 KiB
Markdown
---
|
|
title: Testing Expansion Backlog
|
|
tags: [testing, backlog, qa, release]
|
|
created: 2026-06-06
|
|
---
|
|
|
|
# Testing Expansion Backlog
|
|
|
|
This is the testing backlog to complete before expanding the escrow test suite
|
|
or claiming release confidence.
|
|
|
|
## P0 - Product Policy Gaps
|
|
|
|
### Physical product grace period
|
|
|
|
Need implementation and tests for:
|
|
|
|
- seller marks delivery;
|
|
- buyer receives delivery window;
|
|
- grace period starts;
|
|
- buyer can confirm delivery before expiry;
|
|
- buyer can dispute before expiry;
|
|
- funds release only after buyer confirmation, no dispute, or grace expiry.
|
|
|
|
Acceptance tests:
|
|
|
|
| ID | Expected |
|
|
|---|---|
|
|
| RELEASE-PHYS-001 | Physical delivery starts hold/grace timer. |
|
|
| RELEASE-PHYS-002 | Buyer confirmation before expiry makes funds releasable. |
|
|
| RELEASE-PHYS-003 | Dispute before expiry blocks release. |
|
|
| RELEASE-PHYS-004 | Grace expiry without dispute makes funds releasable. |
|
|
|
|
### Immediate release for gift cards/digital goods
|
|
|
|
Need implementation and tests for:
|
|
|
|
- product type is gift card or digital;
|
|
- seller proof is required immediately;
|
|
- buyer acceptance or product policy triggers immediate/near-immediate release;
|
|
- dispute path can still stop release if policy includes a short challenge window.
|
|
|
|
Acceptance tests:
|
|
|
|
| ID | Expected |
|
|
|---|---|
|
|
| RELEASE-DIGI-001 | Gift card delivery does not use physical-product grace period. |
|
|
| RELEASE-DIGI-002 | Gift card proof advances to releasable immediately after buyer acceptance. |
|
|
| RELEASE-DIGI-003 | Wrong/missing proof blocks release. |
|
|
|
|
## P0 - Dispute Coverage
|
|
|
|
The dispute mechanism is not complete enough for end-to-end fund movement.
|
|
|
|
Tests needed:
|
|
|
|
| ID | Scenario | Expected |
|
|
|---|---|---|
|
|
| DISPUTE-001 | Buyer opens dispute after seller delivery, before release | payment/request enters dispute hold |
|
|
| DISPUTE-002 | Seller cannot force release while dispute is open | release attempt rejected |
|
|
| DISPUTE-003 | Admin resolves for seller | release becomes available |
|
|
| DISPUTE-004 | Admin resolves for buyer | refund becomes available |
|
|
| DISPUTE-005 | Duplicate dispute resolution | idempotent or rejected safely |
|
|
| DISPUTE-006 | Dashboard dispute route vs release-hold route | no route shadowing ambiguity |
|
|
|
|
## P0 - Payment Negative Tests
|
|
|
|
**Automated as of 2026-06-08** (`backend/__tests__/payment-edge-cases.test.ts`, 38 tests):
|
|
See [[Payment Safety Edge Cases]] for full detail.
|
|
|
|
- ✅ wrong token (on-chain `wrong_token` + direct-balance `address-token-mismatch` + `payment-wrong-token` event)
|
|
- ✅ wrong chain (direct-balance `address-token-mismatch`)
|
|
- ✅ wrong destination (direct-balance `address-token-mismatch`)
|
|
- ✅ underpayment (`insufficient_amount` on-chain; `underpaid` direct-balance + `payment-underpaid` event)
|
|
- ✅ native coin sent instead of ERC-20 (`wrong_asset` on-chain; stays pending in direct-balance webhook)
|
|
- ✅ OFAC-sanctioned sender blocked (opt-in per seller; direct-balance `fundDirectBalancePayment` AML gate)
|
|
- ✅ smart-contract sender blocked via `TRANSACTION_SAFETY_REQUIRE_EOA_SENDER=1`
|
|
|
|
Still needs automation:
|
|
- duplicate payment (double-credit guard);
|
|
- late payment after cancelled/expired intent;
|
|
- payment with no gas;
|
|
- scanner unavailable during payment;
|
|
- scanner webhook signature invalid (partially covered by `amn-pay-adapter-webhook-signature.test.ts`);
|
|
- balance check baseline missing or stale.
|
|
|
|
## P0 - Authorization and ID Boundaries
|
|
|
|
Add regression tests for cross-store id comparisons:
|
|
|
|
| Route/action | Required test |
|
|
|---|---|
|
|
| buyer delivery confirmation | buyer can confirm even when session id and request buyer id use different stores |
|
|
| buyer delivery confirmation | non-buyer cannot confirm |
|
|
| seller delivery update | only selected seller/admin can deliver |
|
|
| offer acceptance | only buyer/admin can accept |
|
|
| payment check | only buyer/admin/system can advance payment where applicable |
|
|
|
|
## P1 - UI/Browser E2E
|
|
|
|
Add Playwright tests for:
|
|
|
|
- checkout renders BSC Testnet chain label;
|
|
- token contract row shows canonical tUSDT;
|
|
- testnet explorer links are generated correctly;
|
|
- wrong wallet chain shows switch button;
|
|
- insufficient balance warning appears;
|
|
- payment submitted screen waits for scanner confirmation;
|
|
- paid socket/poll fallback transitions to success.
|
|
|
|
## P1 - Notification Assertions
|
|
|
|
Initial reusable E2E helpers are implemented in
|
|
`backend/scripts/smoke/marketplace-e2e-notifications.mjs`. Remaining work:
|
|
|
|
- capture per-user notification baseline;
|
|
- poll `GET /api/notifications` and `GET /api/notifications/unread-count`;
|
|
- optionally attach Socket.IO clients for buyer/seller/admin actors;
|
|
- fail on wrong-recipient notifications;
|
|
- record known notification gaps with route/action and expected recipient;
|
|
- include notification latency in every E2E report.
|
|
|
|
Current dev findings from the first two-round runner report:
|
|
|
|
- `NOTIF-E2E-001` passes for buyer new-offer notifications.
|
|
- Seller new-request fanout passes for privately targeted sellers.
|
|
- Rejected-seller notifications pass by rejected offer `relatedId`.
|
|
- `NOTIF-E2E-002` fails by selected offer `relatedId`; accepted-offer notification is not discoverable with the selected offer id.
|
|
|
|
Acceptance tests:
|
|
|
|
| ID | Expected |
|
|
|---|---|
|
|
| NOTIF-E2E-001 | New seller offer creates a buyer notification and unread-count increment. |
|
|
| NOTIF-E2E-002 | Buyer offer acceptance creates selected seller notification. |
|
|
| NOTIF-E2E-003 | Seller delivery creates buyer notification. |
|
|
| NOTIF-E2E-004 | Buyer delivery confirmation creates seller notification. |
|
|
| NOTIF-E2E-005 | Missing `pending_payment` notification is reported as a known gap, not a silent pass. |
|
|
|
|
## P1 - Concurrency and Performance Profile
|
|
|
|
Initial executable runner and report generator are implemented in
|
|
`backend/scripts/smoke/marketplace-e2e-notifications.mjs`. Remaining work:
|
|
|
|
- worker abstraction for one isolated buyer/sellers/payment/delivery flow;
|
|
- barrier start for simultaneous workers;
|
|
- ramp stages `1, 2, 4, 8, 16, 32`;
|
|
- JSON result per worker;
|
|
- markdown performance profile report per run;
|
|
- infrastructure snapshots before/during/after each stage;
|
|
- stop-condition enforcement.
|
|
|
|
Current dev blocker:
|
|
|
|
- Dev API rate limiting is `100` requests per `900s`, so C2+ ramp runs need a
|
|
fresh window, a lower-polling profile, or a non-rate-limited test environment.
|
|
- `PAYMENT_MODE=record` currently fails because `POST /api/marketplace/payments`
|
|
returns HTTP 500 after offer selection with generated test actors.
|
|
|
|
Acceptance tests:
|
|
|
|
| ID | Expected |
|
|
|---|---|
|
|
| PERF-CONC-001 | C1 completes with all notification assertions. |
|
|
| PERF-CONC-002 | C2/C4 detect no cross-worker state leakage. |
|
|
| PERF-CONC-003 | Report includes p50/p95/p99 API, scanner, notification, and total timings. |
|
|
| PERF-CONC-004 | Runner stops the ramp on P0 notification/payment/ledger correctness failure. |
|
|
| PERF-CONC-005 | Runner separates live-chain mode from scanner-fixture/API-only modes. |
|
|
|
|
## P1 - CI and Deployment
|
|
|
|
Add a deployment smoke checklist artifact after every pipeline:
|
|
|
|
- backend version endpoint;
|
|
- frontend root 200;
|
|
- scanner `/health`;
|
|
- chain 97 token balance check;
|
|
- current Docker image digests;
|
|
- last commit SHA per service.
|
|
|
|
## P1 - Test Data Lifecycle
|
|
|
|
Need cleanup strategy:
|
|
|
|
- flag generated users with run id;
|
|
- archive or tag generated purchase requests;
|
|
- prevent test data from polluting analytics;
|
|
- define whether test tx/payment rows are permanent audit evidence or can be purged.
|
|
|
|
## P2 - Observability
|
|
|
|
Add dashboards/log queries for:
|
|
|
|
- scanner intent lifecycle;
|
|
- balance-check deltas;
|
|
- payment state transitions;
|
|
- delivery status changes;
|
|
- dispute holds;
|
|
- release/refund attempts.
|
|
|
|
## Suggested Next Automation Order
|
|
|
|
1. Fix selected-seller accepted notification related id.
|
|
2. Fix or retire the legacy `POST /api/marketplace/payments` record path.
|
|
3. Run `PAYMENT_MODE=status` through delivery after the dev rate-limit window resets.
|
|
4. Run `PAYMENT_MODE=live` once wallet gas/tUSDT and rate-limit headroom are available.
|
|
5. Add non-buyer delivery confirmation regression test.
|
|
6. Add scanner negative tests for wrong token and underpayment.
|
|
7. Implement physical vs digital release policy.
|
|
8. Add release-policy tests.
|
|
9. Resolve dispute route/policy gaps.
|
|
10. Add dispute-to-release/refund E2E tests.
|