---
title: "Template Test Examples: Import File"
slug: "template-test-examples-import-file"
updated: 2026-10-20T15:22:11Z
published: 2026-10-20T15:22:11Z
canonical: "docs.validatar.com/template-test-examples-import-file"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.validatar.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Template Test Examples: Import File

## What this pack contains

Six template tests that generate their child tests from an uploaded spreadsheet, each shipped with the spreadsheet it was built from:

| 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 |
| Import File Example - Reconciliation by Segment | Table | 15 | A target table, a segment column, and one segment value |
| Import File Example - Business Rule Catalog | Table | 12 | A rule id, the rule in plain language, the condition that marks a violating row, and an allowance |
| Import File Example - Column Check Suite | Column | 24 | A check name, the condition that marks a failing value, and an allowance |

Each template has its own guide:

- [Import File Example: Source to Target Reconciliation](/docs/import-file-example-source-to-target-reconciliation)
- [Import File Example: Referential Integrity Rule](/docs/import-file-example-referential-integrity-rule)
- [Import File Example: Change Over Time](/docs/import-file-example-change-over-time)
- [Import File Example: Reconciliation by Segment](/docs/import-file-example-reconciliation-by-segment)
- [Import File Example: Business Rule Catalog](/docs/import-file-example-business-rule-catalog)
- [Import File Example: Column Check Suite](/docs/import-file-example-column-check-suite)

The concepts behind all six, including the file layout rules and validation messages, are in [Generating Child Tests from an Import File](/docs/generating-child-tests-from-an-import-file). The same six templates with a metadata script in place of the file are in [Template Test Examples: Metadata Script](/docs/template-test-examples-metadata-script).

### One object, many child tests

Without `test.key`, a template gives each catalogued object one child test, keyed by its name. The last three templates show what changes when the file sets `test.key`:

- **Reconciliation by Segment** lists each source table three times, once per source customer. Each table gets three child tests.
- **Business Rule Catalog** keys each row by its rule id. A table gets one child test per rule, up to five here.
- **Column Check Suite** keys each row by column and check. Each column gets one child test per check.

The first three templates use the same mechanism on a smaller scale: `FACT_SALES` and `FACT_PAYMENT` each have two reconciliation rows, and the drift monitor watches two metrics on each of them.

The pack targets the Snowflake sample data warehouse used in Validatar training and demo environments (database `SAMPLE_DW`, schemas `RAW`, `STAGING`, and `STAR_SCHEMA`). Some rows 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 Tests from an Import File](https://admin.cloud.validatar.com/marketplace/62)

The six 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](https://admin.cloud.validatar.com/marketplace/62) 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`
- `import-file-example-reconciliation-by-segment.xlsx`
- `import-file-example-business-rule-catalog.xlsx`
- `import-file-example-column-check-suite.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.

1. In Validatar, open **Marketplace** from the main navigation.
2. Find **Template Tests from an Import File** and choose **Import**.
3. Pick the target project. Validatar opens that project's import screen with the pack loaded.
4. Map the pack's data source, *Sample Data Source - Snowflake Data Warehouse*, to your Snowflake data source.
5. Choose a target folder and commit.

The import creates the six templates with their spreadsheets already attached. Nothing else needs uploading. Open any of them, 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](https://admin.cloud.validatar.com/marketplace/62), 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:

1. Open the template and click **Materialize Child Tests**.
2. Accept the defaults in the dialog. The child tests land in a subfolder named after the template.
3. 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 | 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 |
| Reconciliation by Segment | 15 | 12 | 3 | The `DIM_CLAIM` shortfall above hits 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 |

## 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.

**Re-keying.** If you change the `test.key` values in a file and the child test names stay the same, the first materialization deletes the old child tests without creating the new ones. Materialize a second time, then check the child test count.

## 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](https://admin.cloud.validatar.com/marketplace/62) 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.

## Related

- [Generating Child Tests from an Import File](/docs/generating-child-tests-from-an-import-file)
- [Template Tests](/docs/template-tests)
- [Understanding Child Test Materialization](/docs/understanding-child-test-materialization)
- [Template Test Functions](/docs/template-test-functions)