Skip to content

Fitting tests into the development workflow

dbt testing verifies assumptions about your data and models throughout the development workflow, not just at the end. Tests should be run incrementally as you build models, and strategically before merging code or deploying to production to catch issues early.

Must-know

  • Run dbt build instead of separate dbt run + dbt test commands to test each model immediately after it's created, stopping downstream dependents from running on failure by default.
  • Use dbt test --select model_name or dbt build --select model_name+ to test a specific model and its downstream dependencies during development.
  • Generic tests (unique, not_null, accepted_values, relationships) are defined in YAML under a model's columns: or tests: key, while singular tests are standalone SQL files in the tests/ directory.
  • Tests can be configured with severity: warn versus the default error so that non-critical data quality issues surface without blocking the pipeline.
  • In CI/CD workflows, dbt tests typically run against a temporary schema built from modified code (often via Slim CI with state:modified+) so only changed and downstream models are tested, saving compute.
  • The --store-failures config (or store_failures: true) persists failing test records to a database table, making it easier to debug why a test failed without rerunning it.
Check this objectiveFree · always available

You add the following generic test to a model's schema.yml: models: - name: orders columns: - name: customer_id tests: - not_null: config: severity: warn When you run dbt build and this test fails, what happens?

Your objective map0 tried · 0 right · 31 untouched

What you have tried across dbt Analytics Engineering's objectives, not a readiness score.

Coverage checked against the published exam guide on Aug 5, 2026.

These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.