Test configurable products and add-ons with real published fixtures

Znode 10
Written By

Create a small published product fixture with distinct variants and add-ons, then verify the allowed selections and server-calculated cart result.

Znode 10GuideIntermediateGCG engineering guide
In this guide
  1. Deterministic seed
  2. Catalog definitions
  3. Published projection
  4. Product detail test
  5. Cart validation
  6. Coverage report
The fixture flows from stable seeded catalog data through publication to product-detail and cart checks, with each test layer recorded separately.

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

Create the fixture using stable product and option codes, then read the saved definitions back. Preserve fields owned by administrators. A rerun should reuse the intended records and reject a conflicting definition rather than silently replacing it.

Next, complete the Store assignment and publication steps required by the installed catalog model. Read the product through the same supported path the storefront uses. The JSON below describes desired fixture data and outcomes; your seed adapter maps it to the installed catalog APIs.

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"
  ]
}

The black chair plus care add-on should produce accepted cart lines and a server-calculated total. The white chair is unavailable, and the retired add-on is ineligible, so those two cases should be rejected. Inspect returned line identities as well as the total: the right price attached to the wrong variant is still a failure.

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 results at four points: the catalog definition, the published product read, the buyer's selected configuration, and the cart response. This makes a failure actionable. A missing published option calls for different investigation than an option that renders correctly but is rejected by cart validation.

Version the fixture and retain its expected outcomes with the test. Re-run the relevant cases when the SDK, product model, catalog rules, or publication behavior changes. Add checkout coverage when a change reaches payment or fulfillment; these cart fixtures do not provide that configuration.

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?

Explore how GCG can help

Independent guidance from GCG. Znode is a trademark of its owner. Examples use fictional data and are not official platform documentation. Suggest a correction.

Previous

Localize widget interface text without confusing it with editor content
Next

Where should custom data live in Znode 10?