Skip to content

test: add totals integrity conformance module#64

Merged
damaz91 merged 2 commits into
Universal-Commerce-Protocol:mainfrom
vishkaty:feat/totals-conformance
Jul 24, 2026
Merged

test: add totals integrity conformance module#64
damaz91 merged 2 commits into
Universal-Commerce-Protocol:mainfrom
vishkaty:feat/totals-conformance

Conversation

@vishkaty

Copy link
Copy Markdown
Contributor

What

Adds totals_test.py, a conformance module for the structural invariants of the
totals[] array. business_logic_test.py checks totals arithmetic (via
existence lookups), but nothing asserts the cardinality and sign rules
the spec places on the array itself:

Test Requirement (types/totals.json, types/total.json)
test_single_subtotal_entry exactly one subtotal entry (contains + minContains:1/maxContains:1)
test_single_total_entry exactly one total entry
test_entries_have_type_and_amount every entry carries type and amount (required)
test_additive_entries_non_negative additive well-known types (subtotal, fulfillment, tax, fee) have amount >= 0
test_discount_entry_is_negative subtractive well-known types (discount, items_discount) have amount < 0

Why

Cardinality ("exactly one subtotal/total") and per-type sign are load-bearing
for any platform rendering a receipt, and the SDK model only enforces presence
of type/amount, not these array-level invariants — so a server can regress
them and still pass. These cut across checkout, fulfillment, and discount
responses.

Design

Server-agnostic relative assertions read from the raw response (consistent with
the other modules). test_entries_have_type_and_amount asserts on the raw wire
(int amount, non-empty type) rather than the parsed model, so it catches what
the model's lax coercion would mask. Sub-line (lines[]) and per-entry-currency
cases are intentionally omitted — the spec's totals amount is a bare
signed_amount (no currency), and the reference emits no sub-lines, so testing
them would be vacuous.

Verification

  • New module green against the reference; full suite green alongside it (14
    files, no regression).
  • pre-commit run clean (ruff, ruff-format, codespell).

@damaz91 damaz91 added the status:needs-triage Signal that the PR is ready for human triage label Jul 22, 2026
@carolinerg1 carolinerg1 added status:under-review and removed status:needs-triage Signal that the PR is ready for human triage labels Jul 23, 2026
Adds totals_test.py asserting the structural invariants of the totals[] array
that the suite does not yet check (business_logic only checks arithmetic via
existence lookups):

- exactly one subtotal entry (totals.json contains/minContains/maxContains)
- exactly one total entry
- every entry carries both type and amount (total.json required)
- additive well-known types (subtotal, fulfillment, tax, fee) are non-negative
- subtractive well-known types (discount, items_discount) are negative

Server-agnostic relative assertions read from the raw response, so any
conformant business passes. Sub-line and per-entry-currency cases are omitted
because the reference emits neither (they would be vacuous).
@vishkaty
vishkaty force-pushed the feat/totals-conformance branch from 00d3e4f to c69fbce Compare July 24, 2026 04:14
@damaz91
damaz91 requested review from damaz91 and removed request for DanielFalconGuedes and jingyli July 24, 2026 08:08

@damaz91 damaz91 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, as usual!

Corrected 'recognised' to 'recognized' and 'recognise' to 'recognize'.

TAG=agy
CONV=30b2df92-7e75-488a-90a8-ad262eac8221
@damaz91
damaz91 merged commit b2844cd into Universal-Commerce-Protocol:main Jul 24, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants