Template Test Examples: Import File

What this pack contains

Three template tests that generate their child tests from an uploaded spreadsheet, each shipped with the spreadsheet it was built from. Together they cover the three shapes an import-file template takes in practice:

Template	Level	Rows	What each row supplies
Import File Example - Source to Target Reconciliation	Table	10	A source query, a target query, the target object, a metric label, and a tolerance
Import File Example - Referential Integrity Rule	Column	6	The parent schema, table, and column a foreign key must resolve to, plus an orphan allowance
Import File Example - Change Over Time	Table	9	A metric expression, a percent drift threshold, and how many previous runs form the baseline

Each template has its own guide:

The concepts behind all three, including the file layout rules and validation messages, are in Generating Child Tests from an Import File. This pack is the first in a series. Packs for the other two generation sources, metadata script and metadata driven, will follow the same structure.

The pack targets the Snowflake sample data warehouse used in Validatar training and demo environments (database SAMPLE_DW, schemas RAW, STAGING, and STAR_SCHEMA). Two rows in the reconciliation template and one row in the referential integrity template fail on that database on purpose. The data really is inconsistent there, and a template that only ever passes teaches less.

Where to get it

This pack is published to the Validatar marketplace: Template Test Examples: Import File

The three import files are embedded in the pack and attached to each template on import. To open them in Excel while reading the guides, download the pack from the marketplace listing or, after import, use Generate Import File > Previous Version on each template's File Selection tab. The files are:

import-file-example-source-to-target.xlsx
import-file-example-referential-integrity.xlsx
import-file-example-change-over-time.xlsx

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. If your instance points at a different database, import the pack anyway and edit the spreadsheets to name your own objects (see Customization).
Metadata ingested for that data source. Every spreadsheet row must resolve to 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 Test Examples: Import File 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.
Choose a target folder and commit.

The import creates the three templates with their spreadsheets already attached. Nothing else needs uploading. Open any of the three, go to the File Selection tab, and you will see Using file uploaded on {date} with {n} records.

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.
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-09-11:

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	6	5	1	254 rows in `FACT_SALES` carry a `PRODUCT_KEY` that is not in `DIM_PRODUCT`, and that row allows 0 orphans
Change Over Time	9	9	0	The first run has no history and passes by design. Later runs pass while the metrics stay within their thresholds

Customization

Point the examples at your own data. Every child test comes from a spreadsheet row, so the fastest way to reuse a template is to edit its file. On the File Selection tab, click Generate Import File and choose Previous Version to download the file that is attached, edit the rows, then Upload Import File and materialize again. The guides describe each column.

Keep the file, change the rule. The SQL on each template references the 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.

Add rows for more objects. Append rows and upload. New keys become new children. Rows you remove become children the materialization dialog offers to delete.

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.

Materialize fails with "Upload a file on the File Selection tab". The template was imported without its spreadsheet. Download the pack again from the marketplace listing and re-import it, or upload the matching .xlsx on the File Selection tab.

Upload fails with Invalid meta object. The row names 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 edit the row.

Child tests error instead of failing. Check the data source connection and warehouse. The SQL in these templates runs on Snowflake; the reconciliation file uses TRY_TO_DOUBLE, which is Snowflake syntax.

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.