Your DBT pipeline ran, but Your Data Was Wrong. Here’s the Fix. [DBT Series #4]

A practical guide to DBT generic tests, singular tests, and model documentation that catches silent failures before your stakeholders do.

Henry12 min read·1 hour ago

You can read from here if you are not a Medium member.

In one of the projects I built, an upstream team renamed a column in one of their source tables, total_price became order_value. The staging model didn’t break. It compiled cleanly, ran cleanly, but produced a result: a column full of NULLs that landed in a revenue dashboard. No alert fired. No job failed.

Tests are what close that gap.

They’re the mechanism that catches a silent wrong answer before a stakeholder messages you saying the dashboard numbers were wrong. But tests alone aren’t enough — if the next person on the team doesn’t understand what your models promise, they can’t tell when something has changed.

That’s what documentation handles.

This article is in two parts. Part 1 covers how DBT tests work, the four generic tests, single-test business rules, severity levels, scoping, and how to write descriptions that actually communicate.

Part 2 applies all of it to the TPC-H project — we’ll create two schema.yml files from scratch, add tests and descriptions to both layers, and run the full test.

This article was originally published on Level Up Coding and is republished here under RSS syndication for informational purposes. All rights and intellectual property remain with the original author. If you are the author and wish to have this article removed, please contact us at [email protected].