Mock与Stub测试替身

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

概念与定位

片场里有两种替身，你在监视器前一眼就能分清：Stub 是道具型替身，导演问什么台词，他就照本宣科回答预设好的那一句，多一个字都没有；Mock 是记账型替身，他答完台词还会低头在小本子上写两笔，记下“刚才谁给我递了眼神、我回了几句话、顺序如何”。这两种替身，共同构成单元测试里最常用的测试替身阵容。

在单元测试语境里，“被测系统”就是舞台上的主角，外部依赖（数据库、邮件服务、AI 模型接口）是需要被替代的配角。当你只想让配角“站在那里配合演出”时，用 Stub 就够了；当你担心主角“有没有真的按照剧本做动作”时，需要的是 Mock。理解这一层，是进入测试工程的大门钥匙。

给替身安排岗位时，记住 Stub 是“工具人”，Mock 是“见证人”。你不需要让见证人背台词，也不该让工具人记笔记，选对角色，戏才不塌。

核心区别

散场之后，两种导演的工作方式不同。只关心结果的导演，把 Stub 返回的单据拿过来，看一眼金额对不对就收工回家——这叫状态验证；较真的导演则翻开 Mock 的小本子，核对“主角是什么时候递的单据、递给了谁、说了哪句台词”——这叫行为验证。

对应到代码上，状态验证的断言对象是返回值：被测模块调用 Stub 拿到结果，再与预期值比对。行为验证的断言对象是调用过程：Mock 记录下“被调用了哪些方法、传入了哪些参数、调用了多少次”，测试通过查询这些记录来确认行为符合预期。

举个直白的例子：测一个订单服务，Stub 方式断言“返回的订单状态是已发货”，Mock 方式断言“send 方法被调用过一次，参数收件人是 alice@example.com”。前者测商家的结算逻辑，后者测流程的传递动作，各管一段。

适用场景

现在你坐在导演椅上，手里有两份剧本。第一份剧本里，主角需要知道“今天的快递费价格表”才能算运费——这种事只需要一个人站在那儿报个数字，Stub 出场；第二份剧本里，主角负责“呼叫仓库发货”，你必须确认他真的呼叫了仓库而不是自己把货搬走了——这种交互必须留痕，Mock 上场。

工程上有个简单判断法：如果测试失败只是因为返回值不对，用 Stub；如果测试失败是因为依赖没有被正确调用（顺序、次数、参数不对），用 Mock。读取配置、查数据库、调用计算服务，通常 Stub 足够；发消息、写日志、调第三方 API，通常需要 Mock。

如果你发现测试里塞满了 Mock 才过得去，先别急着写替身，问问设计是否合理。好的单元测试跟好导演一样，能删的戏份绝不硬加。

编写实践

到了实操环节，给替身安排什么装备？Python 里自带 unittest.mock 库，一行 mock.Mock() 就能制造一个多功能替身：用 .return_value 设定 Stub 的预设答案，用 .assert_called_once_with(...) 做 Mock 的行为验证——同一个对象，两种用法，上得厅堂下得厨房。Java 阵营响当当的 Mockito 同理：when(mock.price()).thenReturn(80) 是 Stub 手感，verify(mock).send(email) 是 Mock 手感。

写的时候抓住三条要领：第一，替身只替外部边界，不替内部值对象；第二，Stub 配置写“当碰到什么入参、返回什么结果”，Mock 断言写“期望这个方法被带这些参数调用 N 次”；第三，测试结尾先查行为再查状态，顺序别乱。

在 Python 里，mock.Mock() 对象既能当 Stub 也能当 Mock，这常让新手误以为二者没有区别。其实区别不在工具而在断言动作：你不去查调用记录，它就是个 Stub 的命；你调用 assert_called_*，它就觉醒成 Mock 了。

最佳实践

一个成熟的导演，选替身有几条铁律。第一，替身数量最小化——能用真实组件的地方绝不引入替身，替身只出现在测试与被测代码的真实边界上；第二，命名清楚——stub_price、mock_email_sender 一眼能看出身份，别用 mock1、fake2 糊弄人；第三，先考虑真实依赖——内存数据库、本地测试容器能用就先用，替身是最后一道屏障。

把“测试替身”想象成剧场里的消防通道：修太多反而堵了主路。过度 Mock 会让单元测试变成“自说自话”——测试验证的是 Mock 的行为是否符合 Mock 的配置，而不是真实系统的行为。越少的替身意味着越少的维护负担。

写测试时问自己一句：删掉这个替身，测试会崩吗？如果不会崩，请删。留下必要的最小替身阵容，测试会跑得更快、更稳、更可信。

家族对比

把替身剧场转一圈，你会发现还有几位“编外”成员。Dummy 是背景板演员，只是来凑个人数让构造函数不报错，台词和戏份都不参与；Fake 是“缩略版剧组”，比如用内存版数据库替代真实数据库，它内部有真实业务逻辑但运行得很快；Spy 是“带录音功能的 Stub”，在真身外面包一层记录调用的壳；而 Stub、Mock 两位正是这串能力阶梯上的核心。

• Dummy（哑元）：占位用，无逻辑，比如只传空对象不让构造器崩溃。

• Fake（假实现）：简化版真逻辑，比如内存数据库、静态字典模拟表。

• Stub（桩）：预设返回，管“结果对不对”。

• Spy（间谍）：真实对象 + 调用记录，半 Stub 半 Mock。

• Mock（模拟）：记录调用 + 断言行为，管“过程对不对”。

选替身时，先问自己“我需要哪个档次的能力”，而不是“哪个听起来高级”。Dummy 和 Fake 是 Stub 与 Mock 的邻居，它们一起撑起了测试隔离的地基。

常见陷阱

片场最容易翻车的，是导演自己把道具和账本搞混。第一大事故：把 Mock 当 Stub 用——测试只关心返回值，却给 Mock 加了一堆 verify 断言，结果接口内部稍微改个参数名，测试就哗啦啦全红，修都修不完。第二大事故：过度 Mock——每个类都配一个 Mock，测试跑得慢、改起来累。第三大事故：行为耦合——连“临时变量怎么组合”都去断言，把 Mock 当成了代码显微镜。

深挖下去，问题根子在于：把“实现细节”错当“行为契约”去验证。行为验证应该只针对“对外部世界产生影响的调用”（比如发了邮件、写了消息），而不是针对内部计算步骤。Stub 与 Mock 的正确用法，是三分靠配置、七分靠克制。

记住这个画面：替身是舞台边缘的钢管，扶一把保持平衡就好，别让演员全场抱着钢管跳舞。Stub 与 Mock 用得好，是测试的加速器；用乱套，就是测试的定时炸弹。

AI 应用场景

Python 演示

# demo_mock_stub.py# 演示 Mock 与 Stub 在 Python unittest.mock 中的两种用法from unittest import mock  class OrderNotifier:    def __init__(self, email_sender):        self.email_sender = email_sender     def notify(self, order_id, user_email):        subject = "订单 %s 已发货" % order_id        self.email_sender.send(user_email, subject)        return "sent:%s" % order_id  class DiscountService:    def __init__(self, policy):        self.policy = policy     def final_price(self, order_id, base_price):        rate = self.policy.get_discount(order_id)        return base_price * rate  def test_notify_uses_mock_to_verify_behavior():    # 创建 Mock 替身：记录 send 调用过程    mock_sender = mock.Mock()    notifier = OrderNotifier(mock_sender)     result = notifier.notify(10086, "alice@example.com")     # 行为验证：断言 send 被调用且参数正确    mock_sender.send.assert_called_once_with(        "alice@example.com", "订单 10086 已发货"    )    assert result == "sent:10086"  def test_final_price_uses_stub_to_provide_value():    # 创建 Stub 替身：只提供固定折扣率，不关心是否被调用    stub_policy = mock.Mock()    stub_policy.get_discount.return_value = 0.8     service = DiscountService(stub_policy)     # 状态验证：只断言最终价格    assert service.final_price(7, 100) == 80  if __name__ == "__main__":    test_notify_uses_mock_to_verify_behavior()    test_final_price_uses_stub_to_provide_value()    print("两个测试均通过：Mock 验证了行为，Stub 提供了数据")

1. mock_sender = mock.Mock()创建万能替身，默认能接收任何方法调用并记录过程。
2. mock_sender.send.assert_called_once_with(...)这是 Mock 的“翻账本”动作，断言 send 恰好被调用一次且参数精确。
3. stub_policy = mock.Mock()同一个类也可以当 Stub 用，关键在于你后续如何配置和断言。
4. stub_policy.get_discount.return_value = 0.8Stub 的“喂饭”动作，设定返回值为固定折扣率 0.8。
5. assert service.final_price(7, 100) == 80状态验证：只关心计算结果是否正确，不检查 policy 是否被调用过。

常见误区

面试题