Skip to content
ProductFeaturesPricingDownloadChangelogDocs
Sign inStart free
data quality
Data

Data quality

State what a query should return, and find out when it stops being true.

Read time
4 min
Sections
4

What a test is

A quality test is an assertion attached to a query: "this should never come back empty", "this should return exactly one row per region". It is evaluated automatically after every run of that query.

The failure it catches is the quiet one. A report that errors gets noticed. A report that silently returns nothing — because an upstream job did not land, or a filter now matches zero rows — arrives looking fine and is believed.

Rules

  • Returns at least one row — The blunt one, and the one that catches most breakage.
  • Row count is at least… — For a query you know should hold a floor — daily orders never drop below 50.
  • Row count is at most… — Catches a join that started multiplying rows.
  • Row count is exactly… — For queries that should return one row per known thing.
  • Custom SQL check — Your own query returning a single number, for anything the row count cannot express.

When tests run

Automatically, after every execution of the query they watch — scheduled or manual. There is nothing to remember to trigger.

You can also evaluate on demand, which re-checks against the query's most recent successful run.

Evaluating on demand does not execute the query. If it has never run successfully there is nothing to check, and the test will tell you to run it first.

Severity

A test is either a warning or an error. The distinction is about what you want to happen at 3am: an error is worth waking someone; a warning is worth reading in the morning. Set it deliberately — a test suite where everything is an error trains people to ignore all of it.