FakeKit.Request a demo

QA SCENARIO BUILDER

Build a test pack you can inspect

A test input needs an expected result. Choose cases for FakeKit's common-field schema, retain the fictional labels, and take the pack into your own test environment.

FICTIONAL QA ONLY Local processing · No accounts · No uploads

Expiry and future-date checks use this date, not your device clock.

Cases to include

Expected results describe FakeKit rules. Observed application results must be recorded separately.

Case packNOT VALID

Eight fictional cases ready. Each includes a stated expected result.

8 cases · Reference date 2026-10-02
CaseExpectedIssue fields
Valid common fieldspassnone
Missing required namefailfullName
Expired recordfailexpiryDate
Equal issue and expiry datesfailexpiryDate
Impossible calendar datefaildateOfBirth
Future birth datefaildateOfBirth
Malformed test record IDfailrecordId
Malformed non-valid numberfaildocumentNumber

All displayed common-field rules should pass.

{
  "recordId": "TEST-0001",
  "classification": "FICTIONAL TEST DATA — NOT VALID",
  "validForIdentification": false,
  "documentKind": "document",
  "fullName": "Sample Person 0001",
  "issuer": "Fictional Test Authority",
  "documentNumber": "NOT-VALID-0001",
  "dateOfBirth": "1996-01-01",
  "issueDate": "2024-01-01",
  "expiryDate": "2028-01-01",
  "scenario": "standard"
}

What the pack gives you

Each case contains a fictional input, a rule description, the expected pass or fail outcome and the expected issue fields. The JSON export also records the reference date and schema version. The checklist leaves room to record what your application actually did.

Keep expected and observed results separate

The builder does not run your software, call an API or certify an onboarding process. Expected outcomes describe the common-field rules shown by FakeKit. If your application uses a different schema or date policy, adapt your test and its expected outcome together.

  1. Choose the behavior and an explicit reference date.
  2. Download a case pack and inspect the case inputs.
  3. Map the fictional fields into a development environment you control.
  4. Run your application and record its observed response in the checklist.
  5. Investigate differences before treating any scenario as a passing test.

Eight cases, with permanent test context

The available cases cover ordinary fields, a missing name, expiry, equal issue and expiry dates, an impossible calendar date, a future birth date and two malformed test identifiers. Even the identifier failure cases retain TEST- or NOT-VALID- prefixes. Every input keeps the fictional issuer, non-valid classification and false identification-validity flag.

A repeatable reference date

Reference dates range from 2000 through 2090. The ordinary case uses January dates based on the selected year, so changing the reference date does not silently change which ordinary field should pass. Expiry and future-date expectations use the date in the pack.

Inspect a fictional batch

Check common-field rules and duplicate record IDs.

Explore resource

Compare expected and observed JSON

Inspect changed values, types and missing fields.

Explore resource

Keep the test context intact

Use the pack only for authorized testing.

Explore resource

CONTINUE EXPLORING

Interactive utility

Create fictional test records

Interactive utility

Check a fictional record's structure

Generators

Fake generator: choose a useful test asset