Skip to main content

Environments & .env

PACE runs in several environments — development, QA, demo, and local — and the test suite can target any of them. This page explains how to switch environments, what the .env file is for, and how per-environment data overrides work.

Picking a target environment

Set the TEST_ENV variable before running the tests:

TEST_ENV=qa2 pnpm run test

If you omit TEST_ENV, the suite defaults to dev2.

The available environments and their URLs are:

TEST_ENV valueURLNotes
dev2 (default)https://dev2saas.frontrol.comThe main development environment.
qa or qa2https://qa2saas.frontrol.comQuality-assurance environment.
demo5https://demo5saas.frontrol.comDemo environment.
localhttp://localhost:3000Requires the PACE dev server to be running in the sibling pace-ui-application repo.

You can also override the URL completely for a one-off target:

BASE_URL=https://my-custom-deploy.example.com pnpm run test

The .env file

The .env file is not committed to the repository (it is gitignored). It holds only two categories of values:

  1. Credentials — the username and password used to log in to PACE.
  2. Control togglesTEST_ENV, HEADLESS, and similar switches.

Everything else — project IDs, estimate names, role values, and all the other data the tests use — lives in tests/data/*.jsonc. Keeping credentials out of the data files means data files are safe to commit; keeping most configuration out of .env means the data files are the complete record of what the tests use.

To create your own .env, copy the sample:

cp .env.sample .env

Then open .env and fill in the required fields:

# Required: login credentials
TEST_USERNAME=your.email@example.com
TEST_PASSWORD=yourpassword

# Optional: pick the target environment (default: dev2)
TEST_ENV=dev2

# Optional: set to false to watch the browser run
HEADLESS=true

Per-environment data overrides

Some data values are different between environments — for example, a project might have a different numeric ID in dev2 versus qa2. The tests/data/env/ folder holds override files for this purpose:

FileApplies when TEST_ENV is …
tests/data/env/dev.jsoncdev2 (or any dev* value)
tests/data/env/qa.jsoncqa2 / qa
tests/data/env/local.jsonclocal

An override file uses the same dotted-path keys as the main data files. For example, to use a different project ID in the QA environment:

// tests/data/env/qa.jsonc
{
"projects.acme_construction.id": "QA-PROJ-42",
}

The data resolver merges the override on top of the base file at runtime: the QA environment uses "QA-PROJ-42", while dev2 continues to use whatever value is in tests/data/projects.jsonc.

What to put where — a quick reference

Value typeWhere it lives
Login credentials.env (never commit)
Environment toggle (TEST_ENV).env or the shell command line
Project IDs, names, amountstests/data/{domain}.jsonc
Value that differs per envtests/data/env/{env}.jsonc
Target URL (one-off override)BASE_URL= on the command line