## TL;DR

Unit tests feed the model fixture rows instead of real upstreams. When the model starts selecting a new column (or renames one) and the fixture is not updated, the unit test errors or silently tests stale logic. Sync the fixture to the model current inputs: add the new columns with realistic values, including the edge values the new logic branches on, and rerun the unit test.

```text
agent's unit test mock drifted from the model's real columns
```

## Use this when

- a dbt unit test fails with a missing column or binder style error after the model changed
- the unit test passes but the model fails in real runs on a column the fixture lacks
- fixture rows in the unit test YAML predate a model refactor

## Not for this skill when

- the model change was wrong and should be reverted, the fixture is correctly exposing it
- the failure is a generic test on real data, not a mocked unit test
- you use an older dbt without unit tests, this class of fixture does not exist yet

## Steps

1. Diff the model inputs against the fixture: list the columns the model selects from each ref or source (from its SQL), and list the fixture columns in the unit test given rows for those inputs.
   Verify: column differences between model and fixture are listed explicitly.

2. Update the fixture rows to the current shape: add the new columns, rename changed ones, and remove dropped ones. Keep at least one row exercising each branch of the changed logic.
   Verify: fixture columns match the model inputs exactly.

3. Align formats: fixture values use the YAML format (or csv fixture files) consistently, with types that match (dates quoted as dates need, numbers unquoted).
   Verify: the unit test parses the fixture without type coercion surprises.

4. Run dbt test --select for the unit test (resource type unit_test where your version distinguishes) and confirm pass, then run the model against a small real sample if available.
   Verify: the unit test passes on the synced fixture and the model behaves the same on real sample data.

## Variant phrasings

### expected output drifted too
Model logic changes usually move the expected rows as well. Update expect rows in the same edit and note why in the commit, so reviewers see the intended behavior change.

### fixture lives in csv files
CSV fixtures hide column order and type issues differently than inline rows. Check headers after model changes, not just row values.

Compatibility: dbt-core unit tests, 1.8 and later (and the earlier experimental unit testing in dbt-utils style setups conceptually). Fixtures defined in YAML with given inputs and expect outputs.

## Why it happens

A unit test is only as honest as its fixture. The fixture is a hand-maintained snapshot of the upstream contract, and nothing in dbt forces it to track the model SQL. Model edits therefore drift the fixture silently: the test keeps validating yesterday shape, failing loudly on missing columns if you are lucky, and passing vacuously if the drift hides in unused columns.

## Edge cases / pitfalls

- Add a schema or contract on the real upstream so drift is caught where it starts, not only inside unit fixtures.
- When a model gains a column for a narrow branch, fixture rows that never exercise the branch give false confidence; add the branch row.
- Treat fixture updates as part of the model change checklist in review, like updating tests after any code change.

## Provenance

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