The repository already follows a strong layered testing model. This is one of the project's real strengths and should be part of the public documentation story.
Test layers in the repo
test/core/*for catalog, projection, workflow, entitlement, and store logictest/provider/*for provider adapters and webhook normalizatione2e/*for end-to-end billing workflowse2e/provider-live/*for smaller real-provider contract coverage
Why this structure is right
Billing correctness should not depend mainly on browser smoke tests. The higher-confidence model is:
- pure logic tests for runtime behavior
- fixture tests for provider normalization
- focused live-provider tests for contract drift
What app teams should test
- catalog changes
- webhook routes
- subscription lifecycle projections
- refund behavior
- credit ledger correctness
- provider configuration and secret wiring
Repo-backed examples
The current repository already exercises important runtime paths in end-to-end tests:
- checkout workflow
- webhook workflow and duplicate delivery handling
- subscription projection reads and change preview
- portal session creation
- one-time purchase refunds
- credit grant and consume flows
That matters because the docs can describe behavior that is already covered by the codebase, not just intended API shape.
Practical advice
When your app integrates Purchase, keep app tests focused on your own policy and routing boundaries. Let the SDK continue carrying the heavy billing-state test surface.
Practical recommendation
For most apps, the highest-value additional tests are:
- one route-level checkout test
- one route-level webhook test
- one authorization test driven by entitlements
- one usage-consumption test driven by credits