Pick a scenario before generating data
| Scenario | What changes | What to assert |
|---|---|---|
| Standard | Required fields are populated | The form accepts the configured schema |
| Missing field | The sample person's name is empty | The relevant required-field message appears |
| Expired | Expiry is fixed at 2000-01-01 | Your expiry rule rejects the record |
| Date order | Issue date follows expiry | Your date-order rule catches the contradiction |
An ID card generator or driving license generator is often unnecessary for a QA task. You can test those forms with the same fictional record schema and a documentKind field. The driving-license record adds a TEST-CLASS category and FICTIONAL jurisdiction; it does not represent an actual license entitlement.
Use the fixture in a bounded workflow
- Keep the test-data utility in a development or sandbox workflow.
- Choose the record type and the one failure case you intend to exercise.
- Export JSON if you need the nested record-type fields; use CSV for the shared flat fields.
- Write the expected application behavior alongside the dataset.
- Remove test records before connecting a demonstration to production services.
Standard here means the common fixture fields are populated. It does not mean the record is a valid government identity, nor that it complies with a real issuer's schema. The fixture validator checks FakeKit's test schema only.