Test Plan

The core happy-path commands are in deployment-steps.md Step 5; this plan adds the manual setup, the full case list, and how to handle async waits.

0. Manual prerequisites (seller / browser) — a seller↔skill handshake

These four steps are performed by the SELLER in the browser; the skill CANNOT do them (no catalog-write / no browser). Run them as a handshake: the skill explains the step and pauses, the seller does it and confirms, then the skill proceeds (and polls where a result is async).

1. [seller/browser] Fulfillment URL (AMMP change set). AMMP → Products → SaaS → select the product → Request changes → Update fulfillment options → edit the default Fulfillment URL (this opens a change set). Set it to the branded registration page if ready and integrated with RegistrationUrl; if no page exists yet, set it to the raw RegistrationUrl (main-stack output) purely for testing. Submit the change set. → Seller confirms submitted. The change set takes time to apply; the skill/seller waits until the product is live again before subscribing (poll the product status or retry the subscribe page).
2. [seller/browser] Buyer allowlist. A Limited product allowlists the SELLER account by default — to test as the seller, SKIP this. To test with a DIFFERENT buyer account: AMMP → the product → Update allowlist → add that AWS account ID → submit. → Seller confirms the test account is allowlisted.
3. [seller/browser] Subscribe. Log into the TEST account (seller or the allowlisted buyer), open https://aws.amazon.com/marketplace/pp?sku=<PRODUCT_CODE>, and subscribe. → Seller confirms subscribed.
4. [seller/browser] Set up your account. After subscribing, click Set up your account — the buyer’s browser is redirected to the Fulfillment URL (the branded page, which calls RegistrationUrl; or the raw endpoint in the fallback case). → Seller confirms clicked. The skill then POLLS the subscribers table for the resolved buyer + licenseArn (§1).

1. Async waits — poll, don’t read once

Several results are NOT instantaneous. The skill polls with bounded backoff and reports “still pending, retrying” vs. a real failure — it does not read once and declare failure.

• After Set up your account: ResolveCustomer persists the buyer immediately, but the licenseArn + subscriptionStatus=active come from the License Updated EventBridge event, which arrives after a short delay. Poll the subscribers table (us-east-1) until licenseArn is present. Default poll contract: up to ~5 minutes total, at 15-second intervals (20 attempts). “Timed out” = licenseArn still absent after the last attempt; the skill then reports the timeout as a probable failure (check the fulfillment-URL wiring / the License Updated handler) rather than silently giving up. The bound/cadence is a default an operator MAY raise for a slow catalog.
• Pipeline runs on EventBridge schedules: the discoverer is hourly and the submitter/ submission-expiry run on rate(5 minutes). To validate the natural end-to-end path, poll for the result on the same default contract: up to ~5 minutes at 15-second intervals, after which a still-absent result is reported as a timeout (not a silent pass). To validate immediately, the skill MAY manually invoke the discoverer (meter mode at the matching hourOffset) then the submitter — it SHALL tell the seller which it is doing (waiting for the real schedule vs. a manual trigger).

Poll example (subscribers row):

2. Test cases (full-pipeline mode)

3. Test cases (direct-submit mode)

Direct-submit has no raw table / discoverer / aggregator / cleanup. Substitute:

4. Clean up test data

Remove test rows the seller inserted (and, if a non-seller test account was used, note the allowlist entry). The aggregated_usage audit rows are retained by design.