A data quality test checks that data meets an expectation: a key is unique and not null, a value falls in a range, a foreign key matches, a table is fresh, row counts are plausible. Tests run on real data, often after each load, and stop or flag bad batches.
For example, a nightly load of an orders table might run these checks after it writes: order_id is never null and never repeated; every customer_id exists in the customers table; amount is between 0 and 100,000; the newest order_date is no older than one day; and today's row count is between half and twice yesterday's. If the uniqueness check fails, the pipeline can stop before publishing, or publish and raise an alert, depending on whether a late table or a wrong one does more harm.
Each platform has its own tools: Databricks pipelines can declare expectations that drop rows or fail the update, Snowflake offers data metric functions, and many teams write checks as SQL queries that must return no rows. The checks themselves are simple. The work is choosing thresholds that catch real problems without failing on normal variation, and deciding who is told when one fails.
A data quality test answers whether this data is acceptable today, while a golden test answers whether this code does the right thing. A pipeline needs both: correct logic can still receive bad input, and clean input does not prove the logic. See also data contract and deduplication.
A failing test is most useful when it says what failed, on which rows, and how far from the threshold the data was, so the person on call can decide quickly whether to rerun, fix the source or accept the data. Results kept over time also show trends, such as a row count that drifts down a little every week. See also silver layer.
They complement golden tests, which check the logic on fixed inputs. Emolysis's templates include checks of both kinds where the shape calls for them. See Golden tests on DuckDB for what golden tests do and do not prove.