集成测试前执行数据库迁移遇到的数据依赖问题

核心问题：你忽略了迁移的幂等性要求 #

涉及数据修改的迁移必须具备幂等性——不管执行多少次，或是在空库、已有数据的库中执行，都不能报错或产生不一致结果。你的migration_5失败，根源是它默认数据库中存在低评分用户，没有处理“无符合条件数据”的边界情况。

可行解决方案 #

1. 给迁移添加空数据容错逻辑 #

修改migration_5，先判断查询结果是否为空，仅当存在目标数据时才执行后续更新操作。

SQL迁移示例：

-- 即使子查询无返回结果，UPDATE也只会影响0行，不会报错
UPDATE other_table
SET some_column = 'adjusted_value'
WHERE user_id IN (SELECT id FROM users WHERE rating < 2);

代码型迁移示例（以Python为例）：

# 查询符合条件的用户ID
low_rating_users = db.session.query(User.id).filter(User.rating < 2).all()
user_ids = [u.id for u in low_rating_users]

# 仅当存在数据时执行更新
if user_ids:
    db.session.execute(
        "UPDATE other_table SET some_column = :val WHERE user_id IN :ids",
        {"val": "adjusted_value", "ids": tuple(user_ids)}
    )
    db.session.commit()

2. 拆分结构迁移与一次性数据修正 #

如果该数据修改只是针对生产环境已有数据的一次性调整，而非所有环境都必须执行的逻辑，可以拆分迁移：

• 结构类迁移：仅负责表结构变更，所有环境（包括测试空库）必须执行
• 数据修正类迁移：仅用于生产环境的历史数据调整，测试环境通过配置标记跳过

注意：这种方式需严格管控，避免测试与生产环境的数据库逻辑出现差异。

3. 测试环境前置初始化依赖数据（应急方案，不推荐） #

若暂时无法修改迁移脚本，可在测试流程中增加一步：执行迁移前，往空数据库插入少量满足依赖条件的测试数据（比如1个评分低于2的用户）。但这种方式会增加测试复杂度，且无法从根本上解决迁移的设计缺陷。

总结 #

最稳妥的方案是修改迁移脚本，使其具备空数据场景的容错能力，确保迁移在任何环境下都能正常执行。这是数据库迁移设计的基础原则——永远考虑边界情况，保证迁移的幂等性与环境兼容性。

内容的提问来源于stack exchange，提问作者Andrey