Test configurable products and add-ons with real published fixtures
Build a small synthetic catalog fixture whose published product, option, add-on, price, inventory, and storefront behavior can be read back and tested.
In this guide
Make the fixture small and descriptive
A configurable-product test is only useful when another engineer can understand the intended choices and expected outcome. Create a synthetic parent product, two or three distinct options, one eligible add-on, one unavailable add-on, and a known price or price-rule fixture. Use stable codes such as DEMO-CONFIG-CHAIR rather than real catalog data.
The fixture should identify which values are catalog definition, published projection, buyer selection, cart line, and order outcome. Those stages can differ. A product that exists in an administrative API may still be absent from the storefront if publication, assignment, inventory, or context requirements are incomplete.
- One parent with a small option set.
- One valid and one invalid combination.
- One add-on that changes expected cart details.
- Explicit account or anonymous context.
- Synthetic images and text only.
Seed deterministically and read back
Use stable fixture keys and a dependency order that can be re-run without replacing administrator-owned values. The seed process should report created, existing, and conflicting rows. A no-op rerun is not enough by itself: test partial setup and a conflicting definition so the script demonstrates how it fails safely.
Read back through the same public or supported application path that the test needs. Verify product identity, option labels, assigned add-ons, publish state, and any declared visibility context. Do not rely on a successful write response as proof that the storefront can render the fixture.
This is an application-owned JSON contract for the project runbook and automation. Its field names are defined here; it is separate from Znode configuration and API request formats.
configurable-fixture.json json
{
"fixtureKey": "configurable-chair-v1",
"parentSku": "DEMO-CONFIG-CHAIR",
"buyerContext": "anonymous",
"expectedCurrency": "USD",
"variants": [
{
"sku": "DEMO-CHAIR-BLACK",
"selection": {
"frame": "black"
},
"available": true
},
{
"sku": "DEMO-CHAIR-WHITE",
"selection": {
"frame": "white"
},
"available": false
}
],
"addons": [
{
"sku": "DEMO-CHAIR-CARE",
"eligible": true
},
{
"sku": "DEMO-CHAIR-RETIRED",
"eligible": false
}
],
"cases": [
{
"name": "eligible-choice",
"variantSku": "DEMO-CHAIR-BLACK",
"addonSkus": [
"DEMO-CHAIR-CARE"
],
"expected": "cart-accepts-and-returns-authoritative-total"
},
{
"name": "unavailable-variant",
"variantSku": "DEMO-CHAIR-WHITE",
"addonSkus": [],
"expected": "cart-rejects"
},
{
"name": "retired-addon",
"variantSku": "DEMO-CHAIR-BLACK",
"addonSkus": [
"DEMO-CHAIR-RETIRED"
],
"expected": "cart-rejects"
}
],
"readback": [
"published-parent",
"assigned-variants",
"addon-eligibility",
"buyer-visibility",
"cart-line-identities"
]
}Test the behavior at each boundary
Use component checks for selection controls, defaults, accessibility, and error presentation. Use supported API reads for product and configuration contracts, then browser checks for the published product page and cart. Add a separate checkout scenario with the required payment and fulfillment configuration when the change reaches those boundaries.
Include mobile keyboard use, unavailable choices, empty configuration, removed add-on, stale published projection, account-specific visibility, and cart refresh. If an option changes price or inventory, verify that the authoritative cart result reflects the declared rule. Never teach readers to trust a client-side total.
- Published product detail page.
- Valid and invalid option selections.
- Eligible and unavailable add-ons.
- Cart result and server-side validation.
- Keyboard, narrow layout, and error focus.
Connect the test layers
Record the fixture version, target platform, seed process, readback outputs, and result for each layer. Give API authorization, published visibility, cart calculation, and payment their own assertions so a failure identifies the boundary that needs attention.
Revalidate after SDK or product-model changes, publishing changes, and catalog configuration changes. Retain fixture history so a failed regression can be traced to a known input state.
Fixture boundary
Use only owned synthetic assets and current supported APIs. Include no tenant identifiers or secrets. Explain which test layers the fixture covers and direct readers to relevant platform documentation for setup.
References and further reading
Bring your next engineering question.
Need help building trustworthy commerce test fixtures?
Independent guidance from GCG. Znode is a trademark of its owner. Examples use fictional data and are not official platform documentation. Suggest a correction.