Build fluency in dbt model contracts and unit testing.
0 / 5 completed
1 / 5
During a PR review, a dbt model's output schema keeps changing unexpectedly. Which feature enforces a stable shape?
A dbt model contract enforces the model's column names, types, and constraints at build time. If the SQL produces a different shape, the build fails. This prevents silent schema drift for downstream consumers.
2 / 5
At standup, a dev wants a column declared NOT NULL and enforced by dbt. Where is this defined?
Within a contract, column constraints like not_null, unique, or primary_key declare expectations enforced where the warehouse supports them. They live in the model's YAML config alongside data types. This tightens guarantees beyond loose tests.
3 / 5
In a design review, the team wants to test model logic with synthetic inputs, no warehouse data. Which dbt feature?
dbt unit tests defined in YAML let you supply mocked inputs and assert exact outputs for a model's transformation logic. They run fast and don't depend on real warehouse rows. This isolates logic bugs early.
4 / 5
During a code review, a dev writes a unit test. Which two keys define the mocked inputs and expected output?
A dbt unit test uses given to mock each upstream input's rows and expect to assert the model's output rows. dbt runs the model against the mocks and compares results. This given/expect structure makes the test self-contained.
5 / 5
An incident report shows a downstream BI dashboard broke after a column rename. Which feature would have caught it at build?
A model contract would fail the build when a contracted column is renamed or its type changes, surfacing the break before deploy. Contracts make the model's interface a checked promise. This guards downstream consumers like dashboards.