Test data

Test data is the set of real values — names, IDs, roles, dollar amounts — that a test uses when it interacts with PACE. In PACE E2E these values live in structured JSON files in tests/data/, separate from the test steps.

Why keep data separate from steps?

Keeping data out of the spec and test files brings three benefits:

1. Non-coders can change it. A tester can open tests/data/projects.jsonc, update a project ID, and the test automatically uses the new value — no TypeScript required.
2. Reuse. The same data entry can be referenced by multiple specs. Change it once and every test that uses it picks up the new value.
3. Per-environment overrides. The dev2 environment might have different project IDs than qa2. Override files in tests/data/env/ let you swap values per environment without touching the shared file. See Environments & .env for how that works.

One file per domain

Each .jsonc file covers one area of the application:

File	What it holds
tests/data/projects.jsonc	Project IDs, names, and settings used in tests
tests/data/clients.jsonc	Client names and IDs
tests/data/team.jsonc	Key-member roles and people
tests/data/estimates.jsonc	Estimate names and line-item data
tests/data/change_orders.jsonc	Change-order values
tests/data/programs.jsonc	Program-level data
tests/data/common.jsonc	Credentials references and shared config

The .jsonc extension means JSON with Comments — you can add // comments to explain why a particular value is there.

A real example

Here is the complete tests/data/team.jsonc:

{
  "$schema": "../schemas/generated/team.schema.json",

  "team": {
    "account_manager_smith": {
      "role_id": "Account Manager",
      "person_id": "Smith, Ms. Elizabeth (126)",
    },
  },
}

Breaking it down:

• $schema — Points to a generated JSON Schema file. If you open this file in VS Code, the editor validates your entries and shows autocomplete suggestions for known fields. Mistyped keys get a red squiggle immediately.
• "team" — The top-level namespace. All specs that need team data look here.
• "account_manager_smith" — A readable key that describes the data object. A spec references this with the dotted path team.account_manager_smith.
• "role_id" / "person_id" — The concrete values the test will type or select in the UI. These are exactly what you would enter by hand if you were running the scenario manually.

How a spec references data

In a spec's frontmatter you list the data keys the test needs:

data:
  - team.account_manager_smith

Inside the step list you use the same key's fields by name:

4. Pick the role in the new row's role dropdown
   - method: `grid.selectCellDropdownOption('role_id', newRowIndex, member.role_id)`

member.role_id resolves to "Account Manager" at runtime. Swap the data entry for a different person and the test exercises a different role without touching the spec.

Validating data files

Run this command to check all data files against their schemas:

pnpm run test:validate-data

If a required field is missing or a value has the wrong type, the validator prints a clear error pointing to the problem line. Fix it and run again before committing.