9. Schema checks and semantic contracts

JSON parsing establishes syntax, not a business contract. A payload can be valid JSON while missing an id, using text for a count or containing an unsupported country. Separate structural checks from semantic rules so a failure explains which promise was broken.

A schema can require fields and constrain values, but the chosen schema still needs review. Decide whether unknown properties are ignored or rejected and whether a missing optional field differs from an explicit null. These are API design choices, not automatic benefits of JSON.

The example documents a role with nonempty string id and title plus a finite country vocabulary. It also names the unknown-field policy. The local decoder projects the checked fields, so an unrelated extra field is not exposed through the trusted result.

Check representative valid and invalid payloads independently. A schema test should reject the wrong primitive, but a business test may also need to reject an empty id that is technically a string. Presence, type and meaning are different observations.

The weak check accepts any object because JSON parsing succeeded. It would admit an empty object and a role whose country is a number. A UI may display placeholders instead of crashing, making this contract failure easy to miss visually.

Do not regenerate expected schema rules from the exact response under test. That turns a provider regression into a new expectation automatically. Review intentional contract changes with both producers and consumers.

Create payload cases for a valid role, an empty id, a missing title and an unsupported country. Add one extra-field case under the documented ignore-and-project policy. Begin with the valid baseline and change one field at a time.

State expected acceptance rather than just listing malformed objects. Optional extension: model an optional website that may be absent but cannot be numeric. Keep the basic four required-field cases small and explainable.

Step 1: Write one valid payload. Step 2: Change one required field per invalid case.

The solution varies one contract dimension per case. The extra-field case remains accepted because projection drops unneeded fields. A strict additional-properties policy would produce a different correct answer, so the policy belongs beside the fixtures.

The verifier runs each case through the local decoder and checks that projected valid results contain only allowed fields. It also rejects a weakened shape-only decoder with an empty-id case. These checks do not establish that every future schema revision is compatible.

In interviews, distinguish syntax, structure and semantics using three concrete payloads. Explain missing versus null and the chosen extra-field policy. Avoid saying that a TypeScript interface validates an HTTP response.

Next, apply the same precision to authorization: a response with a perfect schema can still belong to the wrong account.

Optional stretch — after the core task works: Add absent, null and numeric optional website cases.

Computer practice: download the companion lab at https://applydjinn.com/typorithm/qa-lab-20261105.zip. Read its README, install the pinned tools and run the accepted examples before attempting a starter. The mobile reader preserves your reading and self-check progress; the local lab runs browser tests separately.