Testing & CI for Transformations — Week 2 Check
Week 2 of dbt & Analytics Engineering: turning a transformation project into engineered software.
dbt's built-in tests (not_null, unique, relationships, accepted_values) validate DATA. What class of bug do they structurally miss?
Test bloat is real (thousands of tests, hour-long runs, ignored failures). The corpus-backed discipline:
A PR changes a revenue model. Beyond tests passing, what does mature review demand (the Meta Table Compare discipline, dbt edition)?
Source freshness checks (dbt source freshness) guard against which failure the model tests can't see?
dbt model CONTRACTS (enforced column names/types) move which failure earlier?
The strongest argument for treating the dbt project as software (CI, review, environments) rather than 'just SQL':