---
id: TST-COM-CAT-075
title: Pricing Schedules Verification
kind: integration
product_area: commerce
module: catalog
revision: 1
status: draft
product_intent: proposed
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js
implements:
  - ATS-COM-CAT-011-02
  - ATS-COM-CAT-011-03
  - ATS-COM-CAT-011-06
  - ATS-COM-CAT-011-07
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 2
isolation: 'Suite-owned workspace keys and database fixtures, removed by its cleanup hooks.'
binding_evidence:
  - scenario: ATS-COM-CAT-011-02
    source: >-
      services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js#accepts
      periods whose boundary is the same millisecond, and refuses a gap or an overlap of one
      millisecond
  - scenario: ATS-COM-CAT-011-03
    source: >-
      services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js#refuses
      the sold-in period left out (its delete), and the whole schedule’s delete, 409
      period_immutable
  - scenario: ATS-COM-CAT-011-06
    source: >-
      services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js#refuses
      a product choosing a switched-off schedule, 400 schedule_inactive, and leaves its settings as
      they were
  - scenario: ATS-COM-CAT-011-07
    source: >-
      services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js#answers
      the replaced record at version 2: the kept period at version 1, the changed one at version 2,
      the new one inserted, the one left out gone
  - scenario: ATS-COM-CAT-011-07
    source: >-
      services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js#refuses
      a stale version, 409, and a schedule the tenant does not have, 404
evidence:
  - >-
    services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js
  - >-
    services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js#Real:
    PostgreSQL, the persistence service, the triggers of migration `20261018010345`, the execution
    context and its transactions under `rhythm_commerce_app`.
  - >-
    services-commerce:modules/pricing/tests/integration/services/persistence/pricing-schedules.integration.spec.js#Doubled:
    nothing.
execution_constraints:
  - No execution is performed in this documentation back-fill.
verification_boundary: >-
  Bindings identify the existing assertions contributing to each scenario; several suites can
  jointly cover a compound scenario.
---

# Pricing Schedules Verification

## Verification Boundary

The suite calls the persistence, database or composed service layer against the integration database. It verifies committed rows and the refusals asserted by its cases.

## What This Suite Proves

The pricing schedules assertions contribute to the scenarios listed in the register. Each binding retains its exact source test anchor so a reviewer can distinguish an individual contribution from the complete scenario.

## What It Does Not Prove

The register records source inspection only. It establishes no run result, delivery qualification or Product approval.

## Real Dependencies and Test Doubles

PostgreSQL and the services called by the suite are real. External service ports, file storage and queues may use the fixtures declared by the suite and its support helpers.

## Must Not Be Doubled

Keep the asserted database constraints, transactions, service functions and execution contexts real. For API suites, preserve the dispatcher and permission enforcement.