---
id: TST-COM-FUL-010
title: Promotion import
kind: integration
product_area: commerce
module: fulfillment
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: services-commerce
files:
  - >-
    modules/data-operations/tests/integration/services/operations/promotion-import.integration.spec.js
implements: []
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 3
isolation: >-
  Run-created workspace identifiers and fixture records in the prepared test database; concurrency
  cases own their extra connections.
evidence:
  - repository: services-commerce
    path: >-
      modules/data-operations/tests/integration/services/operations/promotion-import.integration.spec.js
    test_titles:
      - 'creates the promotion numbered, in the status the line says, with its code and its history'
      - >-
        updates the same key: the status set as the line says, the missing code added, the code it
        had left alone
      - >-
        refuses a coupon whose name another promotion of the tenant holds with the promotions’ own
        code
      - >-
        writes the redemption applied, counts it on the code and the promotion, and locks the
        promotion’s terms
      - 'allocates the discount to the order’s line, which the sums at commit accept'
      - >-
        refuses a usage naming an order nobody loaded as its own invalid value (the promotions’ own
        refusal of the foreign key)
      - >-
        reads the promotion back by its key: the input as loaded under the live columns, both codes
        as they stand
      - 'reads the usage back by its key: the row’s columns, the 1.0 keys and its allocations'
    scenario_anchors: []
---

# Promotion import

## Verification Boundary

This suite checks promotion import against the prepared PostgreSQL database. Its entry points are the persistence and service functions used by the tests.

## What This Suite Proves

The suite’s source cases exercise the registered boundary, but this back-fill does not map them to a complete capability or feature scenario. The executable record remains useful without an invented scenario binding.

## What It Does Not Prove

Direct service and persistence calls do not establish the full HTTP permission contract, deployed scheduling or browser behavior. No execution result is claimed by this register.

## Real Dependencies and Test Doubles

The database and imported Commerce persistence services are real. Fixtures create the records owned by this run.

## Must Not Be Doubled

Keep the database constraints, row visibility and persistence writes real when claiming this integration coverage. A canned repository response cannot replace the boundary being checked.