重构工单一半在改测试？你的测试绑太死了

Wed, 08 Jul 2026 10:00:00 +0800

上周重构一个核心模块。if-else 堆了六层，改成策略模式，干净多了。

改完跑测试。20 个用例红了 15 个。

不是因为逻辑错了。

是因为测试里 mock 了 ServiceA 调 ServiceB 的顺序，mock 了某个内部方法的调用参数，mock 了某次数据库查询的中间结果。我把内部实现重新组织了一遍，这些 mock 全废了。

花了两个小时改测试。领导问了一句：重构花了一小时，改测试花了两小时。这次重构到底有没有用？

我答不上来。

覆盖率 80%，到底保不保险

先问自己一个问题：如果覆盖率 80%，你敢不敢在核心模块做大规模重构？

犹豫了。说明你心里清楚——现在的测试不是保护重构，是在保护原来的实现。

覆盖率说的是哪些代码被跑了，不是哪些行为被保护了。 这是两回事。

覆盖率告诉你，这一行被执行过。但它不告诉你，如果这一行被重构到另一个文件里，测试会不会无辜飘红。

很多团队的测试写得"对"，但设计得不对。测试跟实现绑太死，重构变成了先改测试再改代码。这不叫安全，叫双重锁定。

有一个判断框架，每次写测试前问自己：

如果完全重写这个函数的内部逻辑，这个测试会怎么变？

测试不动 → 你在测行为 ✅
要改 mock 期望 → 你在测实现 ❌
要改断言值 → 你在测行为，但输入输出不稳，先想想接口合不合理

就这么简单。

测实现 vs 测行为

两个测试一对比，一眼就看清楚了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 测实现：知道内部调了 A 再调 B
func TestProcess(t *testing.T) {
 mockA := new(MockA)
 mockB := new(MockB)
 svc := NewService(mockA, mockB)
 svc.Process(ctx, req)
 mockA.AssertExpectations(t)
 mockB.AssertExpectations(t)
 // 重构后：排序变了、参数变了——全炸
}

// 测行为：知道输入 X 得到输出 Y
func TestProcess(t *testing.T) {
 svc := NewService(realA, realB)
 got := svc.Process(ctx, req)
 assert.Equal(t, expected, got)
}

左边那个测试知道 Service 内部怎么干活——它 mock 了 A 和 B，验证了调用顺序。重构后输出完全正确，测试也照红不误。

Subtests on Zampo Blog

重构工单一半在改测试？你的测试绑太死了

覆盖率 80%，到底保不保险

测实现 vs 测行为