dbt Testing Interview Questions

dbt compiles a generic test into a SELECT statement and runs it against the warehouse. The test passes when that query returns zero rows, and any returned rows are counted as failures (the failure count is reported in the run results). The other options describe mechanisms dbt does not use for generic tests: dbt does not expect a boolean column, does not execute Python functions for SQL generic tests, and does not compare row counts against values listed in YAML.

The accepted_values generic test takes its allowed list under the argument name values (plural), not value. On line 8 the key is written as value:, so dbt receives no values argument and reports a missing required argument instead of checking the column. The fix is to rename that key to values:. The other lines (the version key, model name, column name, and the test nesting under tests:) are correctly structured.

dbt runs a singular test's SELECT statement and checks the result. Each row returned is a record that violates the assertion, so if the query returns one or more rows, the test fails. A query that returns zero rows means no violations were found, so the test passes. Singular tests are plain SQL files and do not need a schema.yml entry, and they do not use boolean output to signal failure.

dbt ships four generic tests: unique, not_null, accepted_values, and relationships. accepted_values takes a values list and fails any row whose column value is not in that list. relationships takes to: and field: arguments and fails any non-null value that has no matching row in the referenced model's column, which is the referential-integrity check. The other two built-ins, unique and not_null, do not involve a fixed list or a parent model.

unique and not_null are built-in generic tests. dbt compiles each into a select that returns the failing rows — not_null returns rows where id is null, unique returns values appearing more than once via a group by ... having count(*) > 1. A generic test passes when that query returns zero rows and fails when it returns one or more. With both a NULL and a duplicate present, the two tests run independently and each fails, reporting its own offending rows; dbt does not stop after the first failure — every selected test runs so you see the full picture. The tests check values, not just types (so "both PASS" is wrong), and a column may carry any number of tests (so a compile error is wrong). Generic tests are the cheapest, most common data-quality guardrail in dbt; dbt build would additionally use these failures to skip downstream models.

dbt treats a generic test as a query that selects violating records. The macro's SQL is run against the model, and by default the test passes when that query returns no rows; any returned row marks a failure and the row count is reported. The warn_if and error_if configs (defaulting to '>0' for error) set thresholds on the returned row count, so a test can still pass or only warn when the count falls within the configured bound rather than always requiring an empty result set. This is why the test is written as a SELECT of violating records, and why the default pass condition corresponds to an empty result set, adjustable via threshold configuration.

dbt build is a single DAG-aware command that executes seeds, snapshots, models, and tests together in dependency order, interleaving them node-by-node. Crucially, after building a node it runs the tests attached to that node before proceeding downstream, so a failing test causes dbt to skip the dependent models rather than build them on top of bad data. That early-stop behaviour is the main reason build is preferred in CI/production over a separate dbt run followed by dbt test — in the split workflow, every model is built first, so failing tests are discovered only after bad data has already been written and propagated downstream. The claim that dbt build skips tests entirely is wrong (build very much runs tests), and the claim that it ignores the DAG is wrong (it strictly respects the DAG, never alphabetical order).

True. Source freshness is a property you declare on source definitions in a .yml file, not on models. dbt looks at a loaded_at_field column (or, on supported warehouses, table metadata) to find the most recent load time for each source table, then compares the gap to now against the warn_after and error_after thresholds you configure, emitting a warning or error when raw data has gone stale. This catches a broken or late upstream ingestion (an ETL job that stopped running) before you waste a build transforming stale data — a common pattern is to run dbt source freshness at the start of a pipeline and abort if it errors. It says nothing about whether your dbt models are up to date; that depends on when you last ran them. Because it targets sources, it has no notion of ref() — it is checking the inputs to your project, not its internal nodes.

A dbt generic test is a macro whose body is a SELECT statement. dbt wraps that query and evaluates the result set size, not a returned value. Returning only failing records is the defining convention: an empty result is a pass, and any rows are reported as failures. Severity (error vs warn) then decides whether failures stop the run or just get reported. This is why a custom test that returns a boolean or aggregate scalar would be misread as failing or passing incorrectly.

dbt must first resolve the test name from the YAML definition to a macro during parsing, since nothing can be rendered until the macro is known. Next it invokes that macro with the model and column arguments bound to the target relation and column, which yields a SELECT. That query is executed against the warehouse, and the returned row count determines the outcome: zero rows pass, any rows fail. Only after that outcome is known can dbt record the pass or fail status and failure count in the run results. Each adjacent pair is a strict dependency, since each stage consumes the output of the one before it.