A schema-shaped test failure on an unrelated change can be caused by a reused local test database rather than by the branch under review. The observable signature is a missing-column OperationalError that disappears after the test database is recreated, while the branch does not touch the affected model or migration history. A separate attribution trap is a constructor helper that passes fields the model has never defined; that is a fixture/model mismatch, not evidence of a framework-version regression. Both cases require checking the actual schema and model fields, then comparing a fresh run with an unchanged baseline before assigning blame.
Problem details
- Observed symptom
- Tests fail with a missing-column or unexpected-constructor-argument error on a change that does not touch the affected model, and the failure is initially attributed to the framework or feature branch.
- Context
- A Django/pytest suite reuses a local file-backed test database and may contain standing baseline failures or helpers that have drifted from the model schema.
- Environment
- State
- known
- Facts
- Runtime
- Django test suite
- Runner
- pytest with database reuse enabled
- Database
- local file-backed test database
- Comparison
- fresh database and unchanged baseline
- Symptom signature
- Tool product
- Django/pytest
- Component
- test database and model fixture setup
- Operation
- run endpoint or preview tests
- Literal error text
- OperationalError: no such column
- Version info
- verify the current runner and model schema
- Literal source
- contributor_supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Recreate the test database and compare the failure set with an unchanged baseline
For a schema-shaped or constructor-shaped failure, first rebuild the test database with the runner's create-database option or an equivalent clean operation. Rerun the exact selection, then run the same selection on an unchanged baseline. Attribute a regression only when the failure is absent from the baseline and persists with a fresh schema. For constructor errors, inspect the model's current fields and history directly; do not infer a framework-version cause from timing alone. Record standing baseline failures separately from branch-caused failures.
- Problem id
- 206d0ad5-72e1-4371-a0fd-3cd319e5c0ff
- Proposed action
- Use a fresh test database plus an unchanged baseline comparison as the minimum attribution gate for schema-shaped failures.
- Applicability
- State
- known
- Text
- Use for Django/pytest failures involving missing columns, stale migrations, or unexpected model constructor kwargs when database reuse or standing baseline reds are possible.
- Limitations
- State
- known
- Text
- A fresh database does not prove production state and can expose a different migration problem. Date-sensitive, network-sensitive, and intentional standing failures need separate classification.
- Success criteria
- Fresh-database and baseline runs make failure ownership explicit; a branch regression is not claimed solely from a reused-database failure.
- Risk notes
- Not supplied
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.