data-quality-frameworks

Install great_expectations, run great_expectations init, then build an ExpectationSuite with checks like expect_column_values_to_not_be_null and expect_column_values_to_be_unique. Run it through a Checkpoint that stores results and updates Data Docs.

Add tests in your model's YAML file using built-in tests like unique, not_null, relationships, and accepted_values, plus dbt_utils tests like recency and expression_is_true. You can also write custom generic tests in SQL under tests/generic for reusable logic.

Great Expectations suits source-data validation before transformation, with rich statistical expectations and Data Docs reporting. dbt tests run inside the warehouse alongside models, making them ideal for testing transformed tables and relationships in the same pipeline.

A data contract is a versioned agreement between data producers and consumers defining schema, types, PII classification, quality checks (e.g., SodaCL), and SLAs for freshness and availability. It prevents breaking changes from silently reaching downstream consumers.

Add a SlackNotificationAction to your Great Expectations checkpoint's action_list with a slack_webhook and notify_on set to failure. The checkpoint then posts a rendered summary whenever validation does not pass.

Testing everything creates noise and maintenance burden. Focus on critical columns like primary keys, foreign keys, and fields feeding downstream decisions, and add tests incrementally as real issues surface rather than upfront.