Why Generic tests with parameters in dbt? - Purpose & Use Cases

The Big Idea

What if one simple test could check hundreds of tables without extra work?

The Scenario

Imagine you have many tables in your database, and you want to check if certain columns have no missing values or if values fall within expected ranges. Doing this by writing separate checks for each table and column manually is like checking every light bulb in a huge building one by one by hand.

The Problem

Manually writing tests for each table and column is slow and boring. It's easy to forget some checks or make mistakes. When your data changes or grows, you have to rewrite or copy-paste tests again and again, which wastes time and causes errors.

The Solution

Generic tests with parameters let you write one flexible test that works for many tables and columns. You just give the test some details (parameters), and it automatically checks the right data. This saves time, reduces mistakes, and keeps your tests organized and easy to update.

Before vs After

✗ Before

select count(*) from users where email is null;
select count(*) from orders where order_date is null;

✓ After

tests:
  - name: not_null
    args:
      column_name: email
      table_name: users
  - name: not_null
    args:
      column_name: order_date
      table_name: orders

What It Enables

It enables you to build scalable, reusable data quality checks that adapt easily as your data grows and changes.

Real Life Example

A data team uses generic tests with parameters to ensure no customer IDs are missing across dozens of tables, catching errors early without writing dozens of separate tests.

Key Takeaways

Manual tests for each column and table are slow and error-prone.

Generic tests with parameters let you write one test to cover many cases.

This approach saves time, reduces mistakes, and scales with your data.