重构后单元测试跑不过怎么处理

重构后单元测试跑不过，先不要改断言。失败通常不是同一类原因，有的说明重构确实改变了对外行为，有的只是测试绑定了旧的内部实现（私有方法、调用次数、日志、SQL 字符串）。处理顺序应该是先把失败用例分类，再决定改实现还是改测试；如果顺序反过来，很容易为了跑通测试而把行为变化一起掩盖。

先把失败集合按“编译或导入错误、断言值不同、异常或超时”三类分开，断言值不同再判断是行为变了还是测试耦合了实现。行为变了就改实现或明确接受新行为；耦合了实现就把断言改为可观察输出。改动前留一个能跑通的基线提交，改完用同一命令、同一环境复跑，确认失败集合缩小，并确认没有新增 skip、xfail 或放宽断言。

先确认当前场景和目标

这套处理方式成立的前提是：重构前测试是通过状态，或者至少有一份已知的失败清单。如果连基线都没有，先回到重构前的提交跑一遍，把结果存下来，否则无法判断失败是重构引入的，还是本来就存在。

动手前需要确认几件事：重构前最后一个通过测试的提交号；这次重构动了哪些对外接口（函数签名、返回结构、异常类型、模块路径）；失败用例是集中在某几个测试文件，还是分散在多个模块；本地和 CI 是否用同样的命令和依赖锁文件。这些信息决定了后面是批量修改签名，还是逐个判断行为。

判断条件可以写得简单一些：失败是编译错误、导入错误、依赖注入失败，通常属于机械性适配，改了签名后一起修；失败是断言值不同、异常类型不同、超时，则要逐个看，不能批量改期望值。

# 在重构前的提交上留一份基线，便于后面比较
python -m pytest -q > baseline.txt 2>&1 || true
grep -E "^(FAILED|ERROR)" baseline.txt > baseline_failed.txt

# 重构后跑同一命令，输出对比
python -m pytest -q > after_refactor.txt 2>&1 || true
grep -E "^(FAILED|ERROR)" after_refactor.txt > after_failed.txt
diff baseline_failed.txt after_failed.txt

命令里的测试运行器按项目实际情况替换（如 jest、go test、mvn test），关键是两次使用同一条命令、同一份依赖。

按这个顺序处理

第一步是让测试恢复可运行：先修编译、导入、构造参数这类错误，这时不必纠结断言内容。第二步是逐个判断失败性质，建议按测试文件分组处理，一次只推进一组并单独提交，便于回退。

如果确认是对外行为变了，要区分两种情况：行为变化是这次重构期望中的，还是意外引入的。期望中的变化，应该有明确的验收标准，再据此更新测试；没有验收标准的，先当作缺陷处理，不要直接改期望值。属于测试耦合实现的，把校验点从“内部怎么调用”改成“外部看到什么结果”。

# 改前：绑定内部实现，重构做方法合并或改名时必然失败
def test_create_order():
    repo = Mock()
    svc = OrderService(repo=repo)
    svc.create(payload)
    repo.save.assert_called_once()
    svc._validate_stock.assert_called_once()

# 改后：断言可观察结果，允许内部实现重构
def test_create_order():
    repo = InMemoryRepo()
    svc = OrderService(repo=repo)
    order = svc.create(payload)
    saved = repo.get(order.id)
    assert saved.status == "created"
    assert saved.total == payload["amount"] * payload["qty"]

第三步是清理。把为了跑通而临时加上的 skip、xfail、try/except 包一层、assertNotNull 替换 assertEquals 这类改动都找出来，要么补上真实断言，要么在提交说明里写明原因和后续处理人。临时绕过可以存在，但不能和重构混在同一个提交里，否则后面没人说得清测试为什么被削弱了。

改完后怎么验证

验证的第一动作是复跑：用与基线完全相同的命令和依赖版本全量跑一次，把结果和 baseline_failed.txt 对比，确认失败集合只减不增，并且每个减少项都能对应到具体处理动作。如果失败数量下降但出现了新的失败用例，说明改动引入了连带影响，需要回到上一步。

第二动作是拆分跑：单独跑被修改的测试文件，再跑全量，有条件的话换一次执行顺序或用随机顺序跑，确认没有引入用例间依赖。第三动作是反向检查：故意把被测试的实现改坏一行，看测试是否会变红；如果改坏了还通过，说明断言已被放宽，需要补回来。

预期信号包括：全量测试在同一环境下稳定通过；连续跑两三次结果一致，没有偶发失败；测试文件里没有新增 skip 或 xfail 标记；CI 上的结果与本地一致。如果 CI 仍失败而本地通过，优先检查依赖锁文件、环境变量、时区、并发端口和数据库初始状态这些差异。

容易忽略的边界

版本相关：测试框架、mock 库、断言库的小版本升级可能改变匹配规则或默认严格模式，升级锁文件应当单独提交，不要和重构提交混在一起，否则排查失败原因时会多一层干扰。

环境与状态相关：依赖系统时间、随机数、时区、并发顺序、本地端口、共享数据库的用例，重构后失败可能只是被放大了偶发性。这类用例不适合直接标记为已修复，建议先隔离成独立标记，再安排单独排查。需要外部网络或第三方服务的集成测试，在环境不稳定时应从默认测试集中剥离，而不是删除。

回退建议：如果为了让测试通过需要修改大量测试文件，或者开始出现“改了 A 用例又坏了 B 用例”的连锁反应，说明这次重构的粒度太大。此时回退到重构前的提交，把改动拆小，按照“接口变更 + 测试适配”成对提交，比在一个大提交里继续追查更可控。另外，如果失败来自有意的产品行为变更但当前没有验收标准，不要靠改测试绕过去，先确认期望行为再动手。