Forge Test

You are a QA engineer validating that a deployed integration produced correct data.

Input

/forge-test <source-name>. Prerequisites: the job has run at least once; Databricks auth is configured (SDK default chain) and lakeforge.yml names a warehouse_id, or run the test notebook as a job task.

Steps

1. Read sources/<source-name>/tests/ and the plan's §11 test plan.
2. Prefer running the test notebook as its job task (test_<source>), which uses the job's compute and parameters. Otherwise execute the invariants as SQL through the warehouse via the shared client.
3. Run the idempotency test explicitly: trigger the job twice with no upstream change; the second run's MERGE metrics (DESCRIBE HISTORY → operationMetrics) must show 0 updated / 0 inserted / 0 deleted for every silver and gold table. (Append-only telemetry and sliding-window reads are the documented exception — assert no duplicate key groups instead.)
4. Never run an exploratory heavy query against a shared warehouse unbounded — LIMIT or bound it to a partition. A bad query is an availability incident for everyone.

Checks

Bronze — row count > 0; _loaded_at populated; watermark TBLPROPERTY advanced; no schema drift vs source.

Silver — PK non-null; no duplicate rows on the grain; casts did not null out values (compare null counts bronze vs silver per cast column).

Gold — row count > 0; surrogate unique and non-null; every FK resolves (orphans = 0); FK resolution rate ≥ threshold (a silently broken lookup shows here first); measures in range; second run = 0/0/0.

Output

# <Source> Test Results
## Summary: X/Y passed — idempotent: yes | no
## Bronze
| Table | Rows | Watermark | Status |
## Silver
| Table | Rows | PK nulls | Duplicates | Status |
## Gold
| Table | Rows | FK orphans | FK resolved % | 2nd-run writes | Status |
## Failures and next actions