Data tests should capture assumptions, not just failures

A test should name the assumption

Data quality checks are most useful when they document an assumption that downstream logic depends on. “This column is not null” is useful when the reason is clear: it might be a primary key, a join key, or a timestamp used for incremental processing.

dbt describes data tests as assertions about models and sources. Built-in tests such as unique, not_null, accepted_values, and relationships are simple, but they become powerful when they are attached to the assumptions that would break a report, a pipeline, or a publication.

Start with failure impact

Before adding a test, ask what a failure would mean:

1. Would rows be dropped by a join?
2. Would a metric double count records?
3. Would a downstream consumer receive stale or incomplete data?
4. Would a value be syntactically valid but semantically wrong?
5. Should the failure stop the pipeline or create a warning for review?

Great Expectations separates expectations from validation results and allows severity to communicate business impact. That distinction matters: not every quality issue deserves the same response. A schema-breaking missing key might be critical. A rare out-of-range value in exploratory data might be a warning.

Return useful failing rows

A data test that only says “failed” creates follow-up work. A useful test should return enough context to investigate the failure quickly. For example, if an order status is outside the accepted list, the failing rows should include the order ID, status, source system, and extraction timestamp when those fields are available.

This makes failures reviewable instead of mysterious. It also helps distinguish source-data drift from transformation bugs.

Test sources and outputs differently

Source tests check what arrived. Model tests check what the transformation guarantees. Both are needed, but they answer different questions.

• Source checks catch upstream changes before transformation logic hides them.
• Model checks verify keys, relationships, accepted values, and aggregate assumptions after transformation.
• Publication checks confirm the artifact being shipped is internally consistent and current.

For data pipelines, treat tests as part of the contract between stages. A passing build should mean more than “the SQL ran.” It should say which assumptions were checked, which warnings were accepted, and which outputs are safe to use.

Sources

• dbt data tests for assertions, generic tests, singular tests, failing rows, and source/model testing guidance.
• Great Expectations: Try GX Core for expectations, validation results, severity, and failed-record context.

Technical references reviewed on 22 September 2026. This article is general data-quality guidance, not a claim about a specific production pipeline.