## TL;DR

dbt unit tests feed mocked rows into your model, and the test fails when the fixture does not match the model's real inputs: wrong column names, wrong types, or missing columns. Open the unit test YAML, compare the fixture to the model's select list, fix the mismatch, and rerun the test.

## Error

```text
dbt unit test failed on mocked ref data
```

## Steps

1. Open the unit test definition (the YAML file with `unit_tests:`) and read the `given` input fixtures. Expected: you see the mocked rows and their columns.
2. Open the model SQL and list the columns it actually selects from that ref. Expected: you have the true column list to compare against.
3. Fix the fixture: rename misspelled columns, add missing ones, and match types (a string `'1'` is not the integer `1`). Expected: fixture columns match the model's expectations exactly.
4. Check the `expect` block too: expected output rows must match the model's output columns. Expected: both sides of the test are consistent.
5. Run `dbt test --select [UNIT TEST NAME]`. Expected: the unit test passes.

## When to use

- A dbt unit test fails and the failure involves the mocked input rows.
- You just changed the model's columns without updating the test.

## When not to use

- The fixtures are right but the model logic is wrong (fix the model).
- The failure is a parse error in the YAML (fix the YAML structure).

## Tool compatibility

- dbt Core 1.8 and later (unit tests are a 1.8+ feature), all adapters.

## Variant phrasings

### Unit test fails: column not found in mock

The fixture is missing a column the model selects; add it.

### Unit test passes the wrong rows to the model

The `input` ref name in the fixture does not match the ref the model uses.

## Why it happens

Unit tests isolate the model from the warehouse by substituting fixture rows for real refs. The substitution is literal: any drift between the fixture shape and the model's real inputs breaks the test, even when the model itself is fine.

## Edge cases

- Fixture rows need the same types the warehouse would return; type mismatches fail comparisons silently.
- Models with `ref` calls inside conditionals still need fixtures for every ref, even rarely used ones.
- Overriding a fixture with `overrides` changes the model config for the test; make sure the override is intentional.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_f0rZ2uww14bHCPGnCgusVA