Testing

nhic_dbt uses dbt’s built-in test framework to validate data quality at every layer. Tests run in CI on every PR and block merges when they fail.

Schema tests

Schema tests are declared in YAML files (typically schema.yml) alongside the models they test. dbt ships four built-in generic tests:

Example declaration:

# models/staging/cemr/schema.yml
models:
  - name: stg_cemr__patients
    columns:
      - name: patient_id
        tests:
          - not_null
          - unique
      - name: national_id
        tests:
          - not_null
      - name: gender
        tests:
          - accepted_values:
              values: ['M', 'F', 'U']

Custom generic tests

Project-specific tests that are reused across multiple models live in the tests/ directory as generic tests. These follow the same YAML declaration pattern and are referenced by name in schema.yml files.

Use custom tests for domain-specific assertions — for example, validating that a date falls within an expected range, or that a facility code exists in the seeds reference table.

Running tests

# Run all tests
dbt test
 
# Test a specific layer
dbt test --select staging
dbt test --select intermediate
 
# Test models with a specific tag
dbt test --select tag:dwh
 
# Test a single model
dbt test --select stg_cemr__patients

CI test gate

Tests run automatically in .github/workflows/dbt.yaml on every PR targeting main. The workflow runs dbt build (which executes seeds, models, and tests in dependency order) against the CI environment.

A failing test blocks the PR merge. Fix the underlying data or model logic — do not skip tests to unblock a merge.