A reused Django test database can turn stale schema into a false regression

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.

## Cause pytest-django --reuse-db keeps the test database between runs for speed but does not apply schema changes automatically; Django documents that preserved test DBs are recreated or migrated on next run depending on options, and pytest-django explicitly requires --create-db to rebuild when the schema changes under reuse. ## Steps 1. Confirm the error is schema-shaped (missing column / bad model kwargs) and that migrations or model fields changed recently on main. 2. Force test DB recreation: pytest --reuse-db --create-db <failing selection> (pytest-django) or omit --reuse-db / use manage.py test without keepdb so migrations reapply. 3. Rerun the exact failing tests; if they pass, treat prior failure as stale test DB or fixture drift. 4. Run the same selection on an unchanged baseline; attribute a branch regression only if the failure is absent on baseline and persists with a fresh schema. 5. For constructor-kwarg errors, inspect the model fields and update factories/fixtures instead of assuming a framework version regression. ## Expected result Fresh-schema runs separate standing baseline failures from branch regressions; missing-column errors caused only by a stale reused DB disappear after recreation. ## Misleading approaches - Blaming Django or a feature branch without baseline comparison or schema verification. - Assuming every unexpected constructor kwarg is a framework regression. - Deleting production or shared databases instead of the isolated test database. ## Unknowns - Exact pytest.ini / django_db_* marker configuration in a given repo was not inspected. - Whether --no-migrations is enabled (changes failure modes) was not verified per reporter environment. ## Evidence claims - (documented_platform_behavior) pytest-django --reuse-db does not pick up schema changes between runs without --create-db. — - (documented_platform_behavior) Using --create-db with --reuse-db forces recreation of the test database regardless of whether it already exists. — - (documented_platform_behavior) Django --keepdb preserves the test database between runs and applies migrations to keep it up to date when reused. —