dbt tests are declarative assertions in dbt that automatically validate data quality during model builds.
dbt tests are assertions written in YAML or SQL that validate data quality and integrity during dbt runs, catching nulls, duplicates, and business rule violations early.
dbt tests assert expected conditions on tables or columns.During dbt test
runs, dbt materializes each assertion as a query and returns PASS or FAIL, giving immediate feedback on data quality.
Automated tests surface bad data at build time, preventing flawed downstream analytics. They act like unit tests for SQL models, enabling continuous delivery and trusted dashboards.
Add a YAML block under models:
or create a SQL test macro.dbt converts the configuration to a SELECT statement that returns failing rows.
# models/my_model.yml
version: 2
models:
- name: my_model
columns:
- name: id
tests:
- unique
- not_null
Generic tests ship with dbt: unique
, not_null
, accepted_values
, and relationships
. Custom tests allow bespoke SQL logic for complex business rules.
Include dbt test
after dbt build
in GitHub Actions or GitLab CI.Fail the pipeline when any test fails to block bad data from production.
Start with generic tests on primary keys and foreign keys. Promote critical custom tests to staging.Tag tests (e.g., severity: error
) for selective runs in CI.
Galaxys SQL editor autocompletes dbt YAML and SQL test macros, highlights failing test queries, and lets teams share endorsed test snippets in Collections for reuse.
Tests run post-build, so they cant prevent bad data load. Heavy custom tests may slow pipelines.Always index columns used in tests to avoid warehouse cost spikes.
dbt tests are lightweight, version-controlled data quality checks that slot seamlessly into CI/CD. Generic tests cover basics; custom tests guard business rules. Tools like Galaxy make authoring and sharing tests faster.
.
Data teams rely on fresh, correct datasets. Without automated validation, silent data errors can cascade into reports and decisions. dbt tests give engineers declarative, version-controlled assertions that fail fast, ensuring trust and enabling continuous deployment pipelines.
Generic tests are parameterized macros shipped with dbt; custom tests are SQL files that house bespoke assertions.
Yes. Use tags and the --select
or --exclude
flags to run only critical tests in prod.
Galaxys editor autocompletes test macros, lets teams endorse trusted tests, and highlights failing rows for quick debugging.
All warehouses supported by dbt—Snowflake, BigQuery, Redshift, Databricks, and more—run tests natively because tests compile to SQL.