Why Data Quality Testing Is Different From Application Testing
Application testing checks whether code does what it's supposed to. Data quality testing checks whether data meets defined expectations — and those expectations can be violated by upstream data changes that have nothing to do with your code.
A customer who changes their email address, a vendor who changes their data format, a source system upgrade that alters data types — all of these can fail your data quality tests without changing a line of your code.
This is why data quality testing must run continuously, not just at deployment.
The Test Types You Need
Completeness tests: Assert that key columns meet minimum null thresholds.
- "Column email must be non-null for at least 95% of records"
- "Column order_id must be non-null for 100% of records"
Sohovi profiles every column in your dataset for completeness and flags the exact rows where values are missing — free to try.
Uniqueness tests: Assert that primary keys are unique.
- "Column customer_id must have no duplicate values"
- "Combination of (order_id, line_item_id) must be unique"
Referential integrity tests: Assert that foreign keys have valid references.
- "Every order.customer_id must exist in customers.customer_id"
- "Every invoice.product_id must exist in products.product_id"
Range and value tests: Assert that values fall within expected bounds.
- "Column revenue must be greater than 0"
- "Column status must be one of: ['active', 'inactive', 'pending']"
- "Column order_date must be between 2020-01-01 and today"
Freshness tests: Assert that data was updated recently enough.
- "Table customers must have been updated within the last 24 hours"
- "Table inventory must have records from today"
Volume tests: Assert that record counts are within expected ranges.
- "Table orders must have at least 50 new records since yesterday"
- "Table products must have between 5,000 and 20,000 records"
Implementation With dbt Tests
dbt (data build tool) includes a built-in test framework perfect for data quality testing:
# In your dbt schema.yml
models:
- name: customers
columns:
- name: customer_id
tests:
- unique
- not_null
- name: email
tests:
- not_null
dbt runs these tests with dbt test. Failures block the pipeline from promoting data to production.
When to Run Tests
- On every pipeline run: Catches data quality problems before they reach downstream consumers
- After data ingestion: Tests data as soon as it enters your system
- Before report refresh: Ensures reports aren't updated with bad data
- On a schedule: For catching freshness and volume anomalies even when no pipeline has run
Sohovi shows you exactly what is wrong with your data — completeness gaps, type mismatches, duplicates — in one clear report.
A test suite that runs and is reviewed is the difference between proactive and reactive data quality management.
