What this pack contains
Six template tests that generate their child tests from a metadata script: a query that Validatar runs at every materialization, whose rows become the child tests. They are the six templates of Template Test Examples: Import File with the spreadsheet replaced by a script. The test SQL, variables, and success criteria are identical, so the two packs side by side show exactly what changes when the list of child tests comes from a query instead of a file.
| Template | Level | Children | Where the script gets its rows |
|---|---|---|---|
| Metadata Script Example - Source to Target Reconciliation | Table | 10 | A mapping list in the script, from which it assembles the source and target SQL |
| Metadata Script Example - Referential Integrity Rule | Column | 7 | INFORMATION_SCHEMA, by naming convention, with a short overrides list |
| Metadata Script Example - Change Over Time | Table | 17 | INFORMATION_SCHEMA: a row count for every star schema table, a total for every fact amount column |
| Metadata Script Example - Reconciliation by Segment | Table | 15 | A list of table pairs crossed with the customers found in the data |
| Metadata Script Example - Business Rule Catalog | Table | 12 | A rule list in the script, standing in for a rules table |
| Metadata Script Example - Column Check Suite | Column | 24 | INFORMATION_SCHEMA columns joined to a list of checks by kind |
Four scripts return exactly the child tests their file twins produce. The referential integrity and change over time scripts derive their lists, so they find objects the files never named, and their guides explain the difference.
Each template has its own guide:
- Metadata Script Example: Source to Target Reconciliation
- Metadata Script Example: Referential Integrity Rule
- Metadata Script Example: Change Over Time
- Metadata Script Example: Reconciliation by Segment
- Metadata Script Example: Business Rule Catalog
- Metadata Script Example: Column Check Suite
The concepts behind all six, including the rules for the script's result and the Preview & Validate messages, are in Generating Child Tests using a Metadata Script.
One object, many child tests
Every script returns a test.key, and in five of the six one catalogued object appears on several rows. A fact table gets a row count and one total per amount column. A source table gets one reconciliation per customer. A table gets one child test per business rule, and a column one per check. The key is what keeps those rows apart, and the script decides how many there are each time it runs.
Where to get it
This pack is published to the Validatar marketplace: Template Tests from a Metadata Script
Each script is stored on its template and imported with it. To read the scripts outside Validatar, download the pack from the marketplace listing. Each guide also shows its script in full.
Prerequisites
- Validatar Cloud or Validatar Server with a template test license.
- A project you can create tests in.
- A Snowflake data source whose catalog contains
SAMPLE_DW. Any Validatar training or demo instance has one, usually named Sample Data Source - Snowflake Data Warehouse. The scripts run on the same data source, so its schema metadata connection must be able to readSAMPLE_DWand itsINFORMATION_SCHEMA. - Metadata ingested for that data source. Every row a script returns must name an object already in the catalog.
Import
Marketplace content imports directly. Validatar stages the pack and asks where it should land.
- In Validatar, open Marketplace from the main navigation.
- Find Template Tests from a Metadata Script and choose Import.
- Pick the target project. Validatar opens that project's import screen with the pack loaded.
- Map the pack's data source, Sample Data Source - Snowflake Data Warehouse, to your Snowflake data source. This one mapping covers both the templates and their scripts.
- Choose a target folder and commit.
The import creates the six templates with their scripts attached. Open any of them, go to the Metadata Script tab, and click Preview & Validate to see the rows the script returns on your catalog.
Importing from a downloaded file
Download the pack XML from the marketplace listing, then in the target project open Import, select the file, map the data source, and commit. The steps after that are the same.
Materialize and run
For each template:
- Open the template and click Materialize Child Tests. Validatar runs the script and lists the child tests it will create.
- Accept the defaults in the dialog. The child tests land in a subfolder named after the template.
- Run the template, or add the subfolder to a job.
Expected results against SAMPLE_DW, verified 2026-10-19:
| Template | Children | Pass | Fail | Why the failures are expected |
|---|---|---|---|---|
| Source to Target Reconciliation | 10 | 8 | 2 | RAW.CLAIM has 54,339 rows and STAR_SCHEMA.DIM_CLAIM has 53,313. STAGING.S_FACT_EXPENSE_10 has 65,959 rows and STAR_SCHEMA.FACT_EXPENSE has 46,403 |
| Referential Integrity Rule | 7 | 6 | 1 | 254 rows in FACT_SALES carry a PRODUCT_KEY that is not in DIM_PRODUCT |
| Change Over Time | 17 | 17 | 0 | The first run has no history and passes by design |
| Reconciliation by Segment | 15 | 12 | 3 | DIM_CLAIM is short of RAW.CLAIM for all three source customers |
| Business Rule Catalog | 12 | 10 | 2 | 230 rows in DIM_POLICY and 5,755 in FACT_PAYMENT were modified before they were created |
| Column Check Suite | 24 | 24 | 0 | The checked amount and date columns are clean |
Because the scripts run at every materialization, the counts follow the warehouse. Add a table to STAR_SCHEMA and the change over time template picks it up the next time it is materialized. Add a customer to RAW.ACCOUNT and the segment template adds five child tests for it.
Customization
Point the examples at your own data. Edit the script on the Metadata Script tab, click Preview & Validate, save, and materialize. The guides describe what each script returns.
Keep the script, change the rule. The test SQL references a row only through {{schema.name}}, {{table.name}}, {{column.name}}, and {{var.*}}. Edit the SQL on the Test Definition tab and re-materialize. The existing children are updated in place because their keys have not changed.
Read the list from a table. Two scripts carry a list inline (the reconciliation mappings and the business rules) so that the pack runs anywhere SAMPLE_DW does. In production, replace the inline list with a query on the table where your team keeps it. Pick that table's data source on the Metadata Script tab if it lives somewhere else.
Schedule materialization. A job can materialize the templates before it runs them, so derived lists stay current. Read the warning about empty results in Generating Child Tests using a Metadata Script first.
Severity and quality dimension are set on the template and apply to every child. Change them there.
Troubleshooting
Import reports an unknown data source. Map Sample Data Source - Snowflake Data Warehouse to a data source in your instance during import. The mapping step is required.
Preview & Validate reports Invalid meta object. The script returned an object that is not in your catalog. Either the data source does not contain SAMPLE_DW, or metadata has not been ingested since the objects were created. Refresh metadata, or filter the row out of the script.
Preview & Validate reports a script error about INFORMATION_SCHEMA. The scripts read the current database's INFORMATION_SCHEMA. If your data source's schema metadata connection does not open SAMPLE_DW by default, qualify the views as SAMPLE_DW.INFORMATION_SCHEMA.
Child tests error instead of failing. Check the data source connection and warehouse. The SQL and the scripts run on Snowflake. The scripts use VALUES, IFF, $$ string quoting, and INFORMATION_SCHEMA, which need adapting on other platforms.
A Change Over Time child fails on its first run. The template sets Control Missing Result Action to Pass so the first run seeds history. If you changed that setting, the first run has no baseline and fails.