Data Testing

Validate your data at every step. Run dbt tests automatically, see results inline, and catch data quality issues before they reach your stakeholders.

4passed

1failed

1warnings

Why Data Testing?

Bad data erodes trust. When a dashboard shows incorrect numbers, stakeholders lose confidence in the data team. Systematic testing catches issues early:

• Prevent bad data from reaching production by testing in development
• Catch regressions when model logic changes
• Validate assumptions about source data (nulls, uniqueness, relationships)
• Document expectations about what the data should look like

Test Types

dbdeux supports all dbt test types with a rich visual interface:

Schema Tests

Declarative tests defined in your YAML files:

Test	What it checks
unique	No duplicate values in the column
not_null	No null values in the column
accepted_values	Only expected values present (e.g., status in ['active', 'churned'])
relationships	Foreign key integrity between models

Custom Tests (Data Tests)

Write SQL-based tests for complex business logic:

• Row count comparisons between models
• Financial reconciliation checks (debits equal credits)
• Freshness validation (data is not stale)
• Cross-model consistency checks

Package Tests

Leverage community test packages like dbt_expectations and dbt_utils for advanced validations:

• Distribution checks (is the data normally distributed?)
• Regex pattern matching (do emails match expected formats?)
• Recency checks (was the table updated in the last N hours?)

Test Results

Inline Display

After running tests, results appear directly in the IDE:

• Green checkmark for passing tests
• Red indicator for failures with detailed error messages
• Click any failure to see the failing rows
• Jump from failure to the model code to fix the issue

Test Summary Panel

A dedicated panel shows your project's test health:

• Total tests: passing, failing, warning, errored
• Failure trends over time (are things getting better or worse?)
• Most-failing tests to prioritize fixes
• Test coverage: which models have tests and which do not

CI Integration

Tests run automatically as part of your development workflow:

1. You push a change to a feature branch
2. CI builds the affected models in the staging environment
3. All associated tests run automatically
4. Results are reported back on the pull request
5. Reviewers can see test results before approving

Blocking Merges

Configure critical tests as merge blockers:

• If dim_customers.unique_customer_id fails, the PR cannot be merged
• Prevents data quality regressions from ever reaching production
• Configurable per test (some tests warn, others block)

Freshness Monitoring

Beyond dbt tests, dbdeux monitors source data freshness:

• Define expected update frequency for each source (e.g., "should update every 2 hours")
• Get alerted when sources go stale
• Dashboard showing freshness status across all sources
• Prevent runs from executing against stale data (optional)