--- id: TST-COM-ORD-163 title: Shipping kind: api-lifecycle product_area: commerce module: orders revision: 1 status: draft source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b repository: services-commerce files: - modules/shipping/tests/e2e/shipping.e2e.spec.js implements: - ATS-COM-ORD-005-11 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 2 isolation: The suite creates its own test workspace records and removes them using the fixture cleanup. evidence: - provenance: test source: 'services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js' test_cases: - >- reads the zone made with the world, lists the zones in priority order, replaces one at the version read, and deletes a zone with its strategies - >- refuses a zone with a blank region code 400 naming region_codes and creates nothing; a blank description on a replacement 400, only null clearing it (Q06) - 'refuses a strategy of a kind outside the four 400, and one whose bands are out of order 400' - answers the carrier account with its connection reference and never a secret - >- lets a reader list and read, refuses the reader every write 403 permission_missing, a denied principal 403 app_not_permitted, and no context 401 - 'answers shipping_required false, no option and no charge for a cart of an e-book' - >- answers shipping_required true with the Texas zone’s two options, the flat one selected, the charge in the totals - >- re-rates with the buyer’s choice (five units at 150), and refuses a strategy the zone does not offer 400 shipping_option_unavailable - >- clears the choice on PUT shipping_strategy_id null: nothing stored, the preview back on the first option and its charge (DEF-COM-0868) - >- places the order with the charge, the shipping line on the shipping product after the item line, the ship-to address frozen and the choice in the snapshot - >- dispatches the five unit obligations once paid; the participant picks the three on the shelf and leaves two waiting - >- makes the first wave of the three picked units (0..2), charged what the order paid, and walks it to the handoff - >- leaves the order partially shipped after the first wave: three obligations completed, two still in progress, three units shipped on the line - >- fills the two backorders at the receipt, and the second wave picks the filled units at its creation (3..4) and ships them - >- completes the order’s shipping: every unit shipped, every obligation completed, the shelf down five, the cost facts emitted per wave - 'refuses a third wave: nothing is left to ship (409 nothing_to_ship)' - >- writes the pick-up strategy through the route: no charge, the warehouse to collect from, the instructions - 'offers the pick-up at zero beside UPS Ground for the shirts, with the warehouse it is collected from' - 'selects the pick-up the buyer chose, charging nothing' - >- places the order with no shipping charge and no shipping line, the pick-up and its location frozen in the snapshot - >- makes a pickup shipment of the paid order, on no carrier, and refuses its label 409 operation_not_supported - 'refuses the handover to a reader 403 permission_missing, and one naming nobody who collected 400' - >- hands the pick-up over through the route: collected by the buyer, the line shipped, the order’s shipping complete - completes the order’s obligations at the handover and writes the cost relief through the real port - refuses a UPS account without its Integration Platform connection 400 connection_required - 'rates UPS Ground at the preview through shipping.rate.quote on the account’s connection, as commerce' - >- answers an unknown purchase 200 with the label still requested, and the next purchase 409 label_purchase_in_flight while the carrier cannot say - >- settles the purchase in flight by the lookup: the label the carrier holds on attempt 1, asked again only under its own key, never a second key - >- answers a purchase the platform refused (no_binding) 503 carrier_unavailable with the reason, then buys on attempt 2 - 'keeps a void the carrier refused void_failed, and voids the other label' - 'refuses a label format the contract does not take (gif) 400, asking no carrier' - >- leaves a zpl label sold and never answered (ups:03) in flight: 200 with the label requested under package::1 - >- answers the next purchase with the label sold, asked again under the same key: zpl as a data URI, attempt 1, no second key - >- answers a void whose outcome is not known 503 carrier_unavailable, then voids under the next attempt’s key - >- refuses a note of 201 characters 400 envelope_invalid as payload_does_not_parse at items[0].payload.note, and takes 200 - >- refuses the placement 409 placement_refused with the problem shipping_product_required, naming the profile - 'leaves the checkout open, with nothing placed' scenario_coverage: - scenario: ATS-COM-ORD-005-11 test_cases: - >- refuses the placement 409 placement_refused with the problem shipping_product_required, naming the profile scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. dependency_evidence: provenance: test source: 'services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js' declared_by_test: >- the composed handler, the routes, the workflows, TX-P, the table-backed registry, the Merchandise participant over the inventory tables, the claim functions, the register's dispatcher and worker (the recording publisher stands for SQS; the fixture financial facts for Accounting), the manual carrier, the UPS adapter with the invoke client, the cost stream's real relief port over its layers, PostgreSQL. Doubled: the signing key pair, the other services' tables and the Integration Platform's gateway (the running process's local gateway, `runningCarrierGateway`: the happy path, and each scenario's scripted answers). --- # Shipping ## Verification Boundary The suite drives the composed local API dispatcher and its registered routes. ## What This Suite Proves The registered cases check shipping with their fixture records and assertions. Scenario bindings name only the examples those cases exercise. ## What It Does Not Prove A registered file supplies no run result or verified conformance by itself. Local fixtures do not establish deployed cross-service behavior or complete browser journeys. ## Real Dependencies and Test Doubles PostgreSQL and the exercised Commerce persistence or workflow code are real. Remote service records, clocks and transports follow the suite’s fixtures. ## Must Not Be Doubled The database constraints, role restrictions, locks and transactions exercised by this suite must use PostgreSQL.