dbt Testing Strategy

This hub connects notes for building a complete dbt testing strategy — taxonomy, layer placement, unit test selection, alert routing, and the package ecosystem. Effective dbt testing depends on strategic placement, appropriate severity, and clear ownership, not test count. A suite of 500 tests with 20 perpetually failing is worse than a suite of 100 tests where failures are always resolved.

Prerequisites

• Familiarity with dbt models and YAML configuration
• A dbt project with at least some models deployed
• dbt Three-Layer Architecture — the layer framework referenced throughout

Reading Order

1. dbt Testing Taxonomy The five mechanisms dbt provides for validation: generic tests, singular tests, unit tests, model contracts, and package-based tests. Each answers a different question. This is the conceptual foundation everything else builds on.

2. Unit Tests vs Data Tests in dbt The two-checkpoint model: unit tests gate deployments by verifying transformation logic, data tests gate production by verifying data health. Why you need both and what each category catches that the other misses.

3. dbt Testing Strategy by Layer What to test at each layer — sources, base, intermediate, mart — and why testing intensity should increase toward the edges. Includes the “don’t test your cleanup” principle for base models and the focus on post-join primary key checks at the intermediate layer.

4. dbt Unit Tests When to Write Them Specific decision criteria for the 1% of columns that warrant unit tests: complex string parsing, date edge cases, multi-branch CASE WHEN, window functions, and incremental merge logic. Includes the is_incremental() override pattern.

5. dbt Test Severity and Performance Tuning Configuring warn vs. error severity by test category, the “error in CI, warn in production” pattern, and BigQuery-specific cost optimization with partition filtering and tag-based scheduling.

6. dbt Test Alert Routing and Ownership Routing failures to the right people via meta.owner and meta.criticality tags, tiered alert severity (page → Slack → digest → weekly), the Broken Window principle, and the self-improving system that converts incidents into permanent tests.

Strategic Frameworks

• dbt Testing Decision Framework — A three-question framework and decision tree for choosing the right testing approach. Answers “should this be a unit test or a data test?” with concrete guidance by scenario.
• dbt Testing Pyramid — The layered pyramid for dbt projects: broad data test coverage at the base, targeted unit tests in the middle, anomaly detection and data diffs at the top. Recommended distribution across layers.
• dbt Testing Anti-Patterns — Four common mistakes: over-testing with unit tests, happy-path-only coverage, drifting hardcoded thresholds, and testing warehouse functions. Each with a specific fix.

Package Ecosystem

• dbt-expectations Hub — Statistical and pattern-based tests (50+ from Great Expectations). The row_condition parameter for conditional testing. Essential for business rule enforcement on mart models.
• Elementary for dbt — Anomaly detection instead of static thresholds. Catches unknown unknowns: volume drops, distribution shifts, freshness degradation.
• dbt-audit-helper Hub — Migration and refactoring validation. Row-by-row comparison between two relations to prove equivalence.

Unit Test Implementation

• dbt Unit Testing Implementation — The hands-on companion to notes 2 and 4 above. Covers YAML syntax, mocking dependencies, BigQuery workarounds, file organization, CLI commands, and CI/CD workflows. Start here when you’ve decided you need unit tests and want to implement them.
• dbt Unit Test Patterns Hub — Copy-paste-ready patterns for incremental models, snapshots, window functions, CASE WHEN logic, string parsing, GA4 sessionization, attribution, funnels, and edge cases. The pattern library for real-world unit testing.

Schema-Level Guarantees

• dbt Model Contract Mechanics — Build-time enforcement that prevents model materialization when output schema doesn’t match YAML declaration. For public-facing mart models with downstream consumers.

The Maturity Path

0-50 models: unique + not_null on every primary key. relationships on critical foreign keys. Source freshness on all ingestion sources. All severity set to error.

50-200 models: Layer-specific testing strategy. Slim CI with --select state:modified+. Conditional severity. Establish meta.owner tags.

200+ models: Native unit tests for complex business logic (~1% of columns). Elementary for anomaly detection. Model contracts on all public-facing marts. Tiered alerting.