Verification layers and commands

Fabric uses several test layers because a fast unit test and a real Databricks journey answer different questions. The names shown in GitHub checks describe where a check runs or which boundary it proves. They are not separate Fabric products.

Read the status labels

“Full” means the complete repository gate, not support for every operating system or Databricks cloud. The current certified target boundary is documented in the compatibility matrix.

Choose the smallest useful command

Run focused tests while editing, then expand the scope before opening a pull request.

Fast package loop

From the repository root:

pnpm --filter <package-name> test
pnpm --filter <package-name> type-check

For the published Databricks packages:

pnpm --filter @fabricorg/databricks-testkit test
pnpm --filter @fabricorg/databricks-bdd test

Local BDD loop

No workspace or cloud credential is required:

pnpm --filter @fabricorg/databricks-bdd test:features
pnpm --filter @fabricorg/experiments-api test:features

These scenarios use isolated DuckDB contexts. Use pnpm bdd:pretty for source-annotated output or pnpm bdd:wip to run only @wip scenarios and stop on the first failure.

Repository preflight

pnpm build
pnpm type-check
pnpm test
pnpm check

pnpm test includes package tests, repository documentation contracts, and boundary tests. This is the useful local approximation of the full Linux gate. GitHub also runs clean-package, browser, integration, and Windows jobs in fresh environments.

Run each specialized layer

Boundary contracts

pnpm test:boundary
pnpm docs:verify-contracts
pnpm verify:published-manifests
pnpm verify:databricks-package-exports

Boundary tests are intentionally broad. They catch errors that a package-level unit suite cannot see, such as importing across an architecture boundary or documenting an SDK option that no longer exists.

PostgreSQL integration

Start PostgreSQL 16, set DATABASE_URL, apply migrations, and run the API integration suite:

export DATABASE_URL=postgres://postgres:postgres@localhost:5432/fabric_experiments
export BETTER_AUTH_SECRET=local-only-secret-at-least-32-characters

pnpm migrate
pnpm --filter @fabricorg/experiments-api test:integration

The GitHub integration job provisions PostgreSQL automatically. See the Studio regression guide for a repeatable local database and browser setup.

Browser regression

With the API, Studio, and PostgreSQL running:

pnpm --filter @fabricorg/experiments-studio exec playwright install chromium
pnpm --filter @fabricorg/experiments-studio test:e2e

For the published browser SDK and tag loader:

pnpm --filter @fabricorg/experiments-web test:browser
pnpm smoke:new-project:browser

Playwright reports and failure screenshots are retained by CI. Accessibility checks run against the same rendered journeys rather than a separate mock UI.

Windows portability

Run these commands in PowerShell on Node 22 when reproducing a Windows failure:

pnpm build
pnpm verify:databricks-package-exports
pnpm test:boundary

GitHub runs the supported Windows matrix on every pull request, so a Linux or macOS contributor does not need a Windows workstation for routine development.

Live Databricks BDD and target checks

Use the local profile for most behavior. Use a dedicated least-privilege identity and scratch resources when the assertion depends on Databricks itself:

export DBX_TEST_PROFILE=live
export DBX_TEST_LIVE=1
export DATABRICKS_HOST=https://<workspace-host>
export DATABRICKS_CLIENT_ID=<application-id>
export DATABRICKS_CLIENT_SECRET=<secret>
export DATABRICKS_HTTP_PATH=/sql/1.0/warehouses/<warehouse-id>
export DBX_TEST_CATALOG=<scratch-catalog>
export DBX_TEST_SCHEMA=<scratch-schema>

pnpm --filter @fabricorg/databricks-bdd test:features
pnpm test:databricks:live

Live suites stay serial and clean up resources. They produce structured evidence and native Databricks deep links for failed statements, jobs, and pipelines. Start with the BDD quickstart, then use the live testing guide for permissions and target-specific configuration.

Publish the result to Quality Center

The test runner and the product UI are connected through evidence, not through a hidden CI integration. Publish BDD JSON, live-suite JSON, JUnit XML, or Fabric CLI evidence from any pipeline:

fx login --profile production
fx test publish reports/evidence.json --suite "Databricks release verification"

Quality Center applies the organization boundary, records the source and environment, and makes the result available to release policies. See Quality Center publishing for authentication, tenancy, idempotency, and supported evidence formats.

Recommended developer rhythm

1. Run focused unit tests while editing.
2. Run local BDD for behavior and data contracts.
3. Run the repository preflight before a pull request.
4. Let CI prove Linux, Windows, integration, browser, and boundary behavior in clean environments.
5. Run live Databricks checks for the resources affected by the change.
6. Publish release evidence to Quality Center and investigate any stale or failing required suite before promotion.