---
title: Testing Overview
tags: [testing, qa, e2e, smoke]
created: 2026-06-06
---

# Testing Overview

This section is the home for Amanat test procedures and designed test scenarios.
It complements [[07 - Development/Testing]], which documents the test runners and
repository-level commands.

Use this section when planning or executing end-to-end validation across buyer,
seller, payment scanner, delivery, payout, dispute, and deployment behavior.

## Documents

| Document | Purpose |
|---|---|
| [[Test Environment and Data]] | Environments, accounts, wallets, tokens, and secret-handling rules. |
| [[Test Scenario Catalog]] | Canonical scenarios we have designed or need to extend. |
| [[Payment Safety Edge Cases]] | Five payment edge-case families (OFAC, underpay, native coin, wrong token, contract sender) — design rationale, current behaviour, gaps, and 38-test suite reference. |
| [[Escrow Marketplace E2E Procedure]] | Buyer/seller/request/bid/delivery procedure, including the current two-round flow. |
| [[Scanner BSC Testnet Payment Procedure]] | BSC Testnet tUSDT scanner payment procedure and failure modes. |
| [[Notification Assertion Procedure]] | Required notification checks after every E2E business step. |
| [[Concurrency and Performance Profile]] | Ramp test design, profiling targets, metrics, and report template. |
| [[Marketplace E2E Smoke Runner]] | Implemented backend smoke runner, modes, commands, reports, and current dev findings. |
| [[Smoke and Regression Procedure]] | CLI, CI, and post-deploy smoke checks. |
| [[Testing Expansion Backlog]] | Gaps to cover before broader release confidence. |

## Test Layers

| Layer | Goal | Primary owner |
|---|---|---|
| Unit tests | Validate isolated services, state machines, utilities, components. | Backend/frontend/scanner repos |
| Integration tests | Validate repository adapters, payment orchestration, webhooks, auth, marketplace APIs. | Backend/frontend repos |
| Smoke tests | Fast checks for one deployment target, usually via `BASE_URL`. | Backend scripts |
| Browser E2E | Validate user-visible web flows. | Frontend Playwright |
| Live dev E2E | Validate real dev deployment, CI image, scanner service, BSC Testnet, and test tokens. | QA/operator |
| Concurrency profile | Ramp simultaneous full-flow workers and measure API, DB, scanner, notification, and chain behavior. | QA/operator + backend |
| UAT | Validate product scenarios and acceptance criteria. | Product + QA |

## Golden Path Coverage

The minimum live-dev confidence path is:

1. Admin creates one buyer and at least two sellers.
2. Buyer creates a request with a bounded USDT budget.
3. Each seller submits a bid inside the budget with different amount and delivery timing.
4. Buyer accepts one bid.
5. Buyer funds escrow with BSC Testnet tUSDT.
6. Scanner confirms the token transfer.
7. Seller delivers.
8. Buyer confirms delivery.
9. After every state-changing step, assert notifications for every expected recipient.
10. Flow pauses at the current product-policy boundary: release/grace/dispute automation is not complete.

The current live tested version of this path is documented in
[[Escrow Marketplace E2E Procedure#Reference execution - 2026-06-06]].

## Definitions

| Term | Meaning |
|---|---|
| Dev deployment | `https://dev.amn.gg`, backed by the dev Docker stack on the deployment host. |
| Scanner | Separate in-house AMN scanner service that verifies token payments. |
| Direct-balance rail | Scanner payment mode where balance deltas on a destination address confirm payment. |
| BSC Testnet tUSDT | Test ERC-20 used for dev payments: `0x109F54Dab34426D5477986b0460aE5dFBA65f022`. |
| Grace period | Product-policy delay after delivery before automatic fund release. Not implemented yet. |
| Immediate release | Product-policy mode for digital goods such as gift cards. Not implemented yet. |

## Rules

- Never commit seed phrases, private keys, admin passwords, CI tokens, or `.env` files.
- Use generated test users with unique run IDs. Do not reuse personal accounts for destructive scenarios.
- Record enough evidence to reproduce a failure: request id, offer id, payment id, tx hash, chain id, token address, HTTP status, and CI build number.
- Treat a passing local test as necessary but not sufficient for scanner/payment work. Payment changes must also be verified against dev after deploy.
- Every live-dev test should state what remains untested or blocked.
- Use `backend/scripts/smoke/marketplace-e2e-notifications.sh` for implemented buyer/seller smoke runs before extending scenarios manually.
