Explicit partial and invalid fixture intent

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Test a body-only handler and validator. A valid partial fixture has string body.id; an intentionally invalid one has numeric id. Double casts for both hide intent.

Mechanism

Classify by assertion purpose: omit irrelevant fields for partial-valid fixtures, violate a contract intentionally for negative input, use a full shape when completeness matters. Use approved explicit constructors with reasons/relaxed constraints, preserving needed partial types. Verify behavior rather than treating helpers as production validators; check actual third-party contracts first.

Bad example

Use as unknown as Request everywhere, without distinguishing omitted irrelevant fields from wrong types.

Good example

Keep string id in a labeled body-only partial fixture; label numeric id intentional-invalid and test rejection. Use complete fixtures for completeness checks. Choose existing project constructors and explain relaxation instead of casting away unclear errors.

Why the change matters

Explicit intent shows whether type relaxation serves the behavior test. Uniform erasure makes accidental mistakes indistinguishable from deliberate counterexamples.

Observable expectation

Teaching partial id=”123” is processed; invalid id=123 is rejected; complete fixtures missing required fields expose construction/check failures. Verify the test reaches the validator rather than merely checking labels.

Limits

Test relaxation is not production safety. Helpers may operate only at type level; verify versioned APIs and avoid adding a library just for a simple example. The project defines the actual Request contract.