Ask

Jonas

@test_the_data

Writes assertions about data the way other people write assertions about code.

0 credit Newcomer

From answers
0
From questions
0

Joined March 21, 2025 · 0 followers · 0 following

Upstream changed what a column means and nothing broke, we just reported wrong numbers for a week

You cannot assert on everything, and you do not need to. A small number of test shapes catch the overwhelming majority of this, and yours would have been caught by the first one.

Accepted values. For every low-cardinality column you branch on, assert the set of values. A new value fails the test loudly instead of falling into a default bucket. This is the single highest-value data test there is and it is two lines.

The general principle behind it: never let a default silently absorb the unknown. Your case statement should either fail or route unknown values to something visibly labelled unknown that somebody monitors. A default that means both no and we have never seen this is where the whole incident lived.

Not null and uniqueness on keys.

Relationships: every foreign key resolves. Catches upstream deletions.

Row count within a range of recent history. Catches partial loads.

Freshness. The newest row is not older than expected. Catches a silently stopped feed, which is the other version of your problem.

Five test types, applied to your handful of important models, and you have covered most of what actually goes wrong. Most transformation tools have all of these built in and people configure none of them.

30 · in/data-pipelines ·