Build a small contract fixture set for a product feed
Test missing values and variant mapping on a small fixture set before running a full catalogue export. Each fixture should force a specific decision in the exporter, with an expected result you can explain.
A fixture is a controlled input with a documented expected result. Keep exporter checks separate from delivery and ingestion tests.
Start with one product that can fail in several ways
Consider a synthetic catalogue containing a blue mug and a red mug. Each colour is sold separately. The exporter can produce well-formed JSON while attaching the red image to the blue identifier, dropping a leading zero from a key or inserting a default stock value when the inventory lookup fails. A parser will not necessarily detect these mistakes because the JSON structure can remain valid.
A useful fixture isolates one of those decisions. Keep the input small enough that a reviewer can explain the expected output without running the exporter. Use invented identifiers and public-domain test values, clearly separated from production records.
The OpenAI product specification supplies concrete contract checks. It treats identifiers as strings, requires an explicit recognised availability value and describes separate item, group and seller-offer identifiers. The fixture names below are our proposed test cases; they are not an official conformance suite.
| Fixture | Input change | Expected decision to document |
|---|---|---|
| Leading-zero identifier | Use the synthetic key 00042-BLUE |
Preserve the complete string |
| Unknown inventory | Remove the inventory observation | Use the contract's permitted unknown handling, never assert stock |
| Wrong variant image | Give the blue item the red item's image | Fail the semantic correspondence check |
| Price-only update | Change the confirmed price | Retain the relevant stable identifiers |
| Missing required value | Remove a required field | Report the omission before distribution |
The wrong-image case requires a known mapping in the test data. A generic image URL validator cannot determine which colour the photograph depicts. If image-content review remains manual, record that boundary rather than marking the entire variant check as automated.
Separate the contract oracle from the exporter
The expected result is the test's reference point. If the same mapping function generates both the actual output and the expected output, they can agree while sharing the same error. Write the expectation independently, using the applicable field definition and the known facts in the fixture.
For a price-only update, for example, the test can compare the identifiers before and after the change while separately checking the price. It should not merely compare two files for inequality. A changed timestamp would satisfy that weak test without demonstrating that the price was updated.
A rejected row also needs an observable reason. “Validation failed” is insufficient when a teammate must decide whether to repair the source data, the transformation or the contract reference. Keep the field and the relevant rule next to the result, without copying credentials or unrelated customer data into the log.
Make one failure deliberate before trusting the suite
Run the fixture once with its intended input, then deliberately alter the value the assertion is supposed to protect. If the test still passes after a variant identifier is swapped, the assertion does not cover the risk its name suggests. This is a proposed local test technique, not a claim that your current exporter has been exercised.
The exercise also reveals hidden dependencies. A fixture that relies on a live price or a changing remote page may fail for reasons unrelated to the exporter. Keep deterministic mapping tests separate from the later check of the actual public destination.
Test transformations in isolation
Run the mapping on the fixture before introducing scheduling, transport and credentials. Keep the generated record and the validation result together.
When a test fails, inspect the first point where the meaning changes. Did the source omit a value, did the mapping add a default, or did the destination reject a supported value? Combining these into one “feed error” hides who can fix it.
Then test delivery separately in an authorised test environment. A passing local fixture cannot establish authentication, ingestion or buyer-facing availability.
Make updates reviewable
When a contract changes, compare the old and new expected results. Do not regenerate every expected output and approve the difference automatically. That can make a regression become the new definition of success.
Ask which rule changed, which fixture demonstrates it and whether an existing downstream consumer still relies on the previous behaviour. Add a fixture only when it covers a meaningful new decision.
The Verity Score ACP guide explains the merchant-facing protocol. Resolve field requirements against the platform specification used by your exporter.
Keep the input, expected output, actual output and exporter revision together. When a future contract change breaks a fixture, that record should show whether the code is wrong or the expectation needs a documented update.
Attach fixture results to the relevant production gate, so a failed mapping check can stop the release that depends on it.