---
id: TST-COM-ORD-043
title: Checkouts persistence
kind: integration
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/checkout/tests/integration/services/persistence/checkouts.integration.spec.js
implements:
  - ATS-COM-ORD-001-10
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/checkout/tests/integration/services/persistence/checkouts.integration.spec.js'
    test_cases:
      - 'answers the checkout open, with its items in position order and its system properties'
      - wrote its created event
      - 'refuses a store the tenant does not have, naming the property, and leaves nothing behind'
      - 'refuses an item with a quantity of zero, naming the rule'
      - 'adds the item after the last, bumping the checkout’s version'
      - 'changes the item’s intent and what the participant answered, bumping both versions'
      - 'removes the item, bumping the version, and the events tell the story'
      - 'refuses an item write for an item the checkout does not have, 404'
      - 'refuses a write on another tenant’s checkout, 404'
      - >-
        clears a stored shipping choice when the choice is null, as the shipping route writes it
        (DEF-COM-0868)
      - changes the checkout’s own fields while open
      - 'moves along the lifecycle, the placed checkout naming its order'
      - 'refuses every move out of placed, 409'
      - 'refuses an item write once the checkout is no longer open, 409'
      - 'refuses placed without an order, and any other status with one, 409'
      - 'refuses open to placed (preparing comes first), and lets open go abandoned or cancelled'
      - records each transition as an event with where it came from and went to
      - appends the code as typed and bumps the checkout’s version
      - 'changes nothing for a code already entered in its normal form, naming the one there'
      - 'removes the code matched by its normal form, naming it as it was entered'
      - changes nothing when the checkout carries no such code
      - 'refuses a code write on a checkout that is no longer open, 409'
      - appends a workflow’s event with its actor kind and details
      - 'refuses deleting an open checkout, 409, and deletes an abandoned one with its items and events'
      - answers 404 for a checkout the tenant does not have
scenario_coverage:
  - scenario: ATS-COM-ORD-001-10
    test_cases:
      - 'refuses open to placed (preparing comes first), and lets open go abandoned or cancelled'
      - 'refuses placed without an order, and any other status with one, 409'
      - 'refuses every move out of placed, 409'
    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/checkout/tests/integration/services/persistence/checkouts.integration.spec.js'
  declared_by_test: 'PostgreSQL, the persistence services, the execution context under `rhythm_commerce_app`. Doubled: nothing.'
---

# Checkouts persistence

## Verification Boundary

The suite exercises persistence or workflow operations against the local integration database.

## What This Suite Proves

The registered cases check checkouts persistence 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.