17370845950

Django 测试数据库表缺失与字段未创建问题的完整解决方案

django 运行 `python manage.py test` 时测试数据库仅创建部分表、缺少关键字段(如 `core_division.display_name`),根本原因通常是迁移文件不一致或未正确应用,而非配置错误。本文将系统性排查并修复该问题。

在 Django 中,测试数据库(test database)默认由 manage.py test 自动创建,并基于当前项目的迁移历史(migrations)重建所有模型对应的表结构——它不复用生产数据库的物理结构,也不执行 syncdb 或跳过迁移。你观察到测试库仅生成 47 张表(远少于实际 226 个模型),且关键字段缺失,这强烈表明:Django 在构建测试数据库时未能识别或应用完整的迁移链

? 根本原因定位

Django 测试流程的关键逻辑是:

  • 创建空测试数据库(如 test_myscore);
  • 逐个执行所有 migrations/ 下的迁移文件(按依赖顺序)
  • 若某模型无迁移文件,或迁移文件未被 makemigrations 生成,其表/字段将完全不会出现在测试库中

你启用 'MIGRATE': False 后表数升至 195 且字段存在,恰恰反向验证了这一点:此时 Django 跳过了迁移步骤,直接复用了已有数据库结构(配合 --keepdb),但因未真正运行迁移,后续 ORM 操作(如 save()、filter())会因 schema 与模型定义不一致而静默失败或报错。

⚠️ 注意:'MIGRATE': False 是危险的临时绕过手段,绝不适用于常规测试——它破坏了测试环境的隔离性与可重现性。

✅ 正确修复步骤(推荐顺序执行)

1. 确保所有应用均含有效迁移目录

检查每个 Django app(如 core/, accounts/)下是否存在 migrations/ 子目录,且其中至少包含一个初始迁移文件(如 0001_initial.py)。若缺失,请手动创建:

mkdir -p core/migrations/
touch core/migrations/__init__.py

2. 生成并验证迁移文件完整性

在项目根目录运行:

python manage.py makemigrations --dry-run --verbosity=2
  • 若输出显示“No changes detected”,说明当前模型与迁移文件一致;
  • 若提示“Create model Division”等新增项,说明有模型变更未迁移 → 执行 python manage.py makemigrations 并提交新迁移文件。

3. 检查迁移依赖关系是否断裂

运行以下命令查看迁移状态:

python manage.py showmigrations

重点关注:

  • 是否存在 [ ](未应用)标记的迁移(尤其在 core app 下);
  • 是否有 !!! 标记(表示迁移文件存在但无对应记录,即“未应用但已删除”);
  • 是否存在 SQUASHED 或 REPLACE 类迁移导致依赖混乱。

若有未应用迁移,先在开发库中执行:

python manage.py migrate

4. 清理测试残留并重试(关键!)

删除残留测试库(PostgreSQL 中):

-- 连接到 PostgreSQL(如 psql -U your_user)
DROP DATABASE IF EXISTS test_myscore;

然后干净启动测试:

python manage.py test your_app.tests --keepdb  # --keepdb 便于调试,首次建议省略

5. 验证测试数据库结构

若仍失败,在测试崩溃后立即连接测试库(如 psql test_myscore),执行:

\d core_division

确认 display_name 字段是否存在。若不存在,说明 core app 的最新迁移(含该字段)未被加载——请回到第 2 步复查 core/migrations/ 下是否有类似 0012_add_display_name_to_division.py 的文件,并确保其 dependencies 正确指向前序迁移。

? 配置误区澄清

你当前 TEST 配置中的 'SERIALIZE': False 是合理优化(禁用 fixture 序列化提升速度),但以下选项需谨慎:

  • 'MIRROR': 'default':绝对禁止用于真实测试——它让测试直接操作生产库,存在数据污染与安全风险;
  • 'MIGRATE': False:仅限极特殊场景(如测试迁移本身),且必须配合 --keepdb 和手动 schema 管理,日常开发中应避免。

✅ 最佳实践总结

场景 推荐做法
日常单元测试 使用默认配置(无 TEST 覆盖),确保 makemigrations 已提交、migrate 已执行
CI/CD 流水线 添加预检步骤:
python manage.py makemigrations --check --dry-run(失败则阻断构建)
多数据库测试 为非 default 数据库显式指定 --database=other_db,并在 TEST['MIRROR'] 中正确配置镜像关系

通过以上步骤,你的测试数据库将准确反映全部 226 个模型及所有字段,core_division.display_name 等缺失字段问题将彻底解决,且测试具备完全的隔离性与可靠性。