Write the smallest cart fixture that catches a pricing regression
The only test product costs 100.00, so fractional-price bugs pass. Define a reusable fixture with 19.99 and 0.10 items, quantities, tax, and one promotion.
- Focused work estimate
- 1h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Test data · Money arithmetic · Specification
Estimated field mix
- Quality engineering100%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A small commerce team has happy-path browser tests but still ships rounding and retry defects. Model a fictional shop using synthetic products, a local payment double, and explicit cart rules before adding regression coverage.
Setup prerequisites
- Create or provide a local checkout fixture application.
- Model products, tax rules, inventory, and a payment-provider double using synthetic data.
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Expected totals use integer minor units with the rounding stage explicitly documented.
- The fixture can reset to an identical starting cart between runs.
- Expected values are stated independently of the checkout implementation.
Implementation constraints
- Use a fictional currency with two decimal places for this fixture.
Verification to include
- Check the documented two-item total by an independent integer calculation.
- Change quantity from one to three and verify the expected amount changes without fixture state leaking between runs.
Deliverables
- Synthetic cart fixture and pricing expectation table
Rollout and recovery
Add the fixture as a separate suite seed; reset by run ID instead of clearing shared environments.
Value of the work
For the engineer: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures.
For the team: Review whether a test suite catches business regressions and explains failures without creating noisy release gates.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.