一、为什么需要测试替身
写单元测试的时候，我们总会遇到一个让人头疼的问题。比如你要测试一个处理订单的函数，但这个函数要连数据库、要发短信、要调第三方支付接口。你能在测试里真的去连数据库吗？能真的给用户发一条测试短信吗？能真的往支付宝里充钱再退款吗？显然不能。
这时候就需要"测试替身"来帮忙。测试替身就是用来替换那些在测试中不好直接使用的真实组件的假对象。它能让我们专注于测试自己的代码逻辑，而不被外部依赖干扰。
但是测试替身不是一种东西，它有几种不同的形态，最常见的就是Stub、Fake和Mock。很多人把它们混为一谈，觉得都是一个意思，结果用的时候选错了类型，测试写了一大堆，最后却发现测出来的结果根本不靠谱。
这篇文章就来好好掰扯掰扯这三者之间的区别，让你以后选的时候心里有数，不会再踩坑。
二、测试替身的全局视角
在深入每一个具体类型之前，我们先建立一个整体认知。测试替身本质上都是"替身演员"，但它们的职责完全不同。
2.1 替身演员的分类思路
你可以把测试替身想象成电影拍摄中的不同角色：
- Stub就像一个"道具组"，它只负责在需要的时候给出一个预设好的数据，不管你怎么问，它都按剧本回答。
- Fake像一个"演技派的替身演员"，它能真正跑流程，但用的是简化版的实现，比如用一个内存字典代替真正的数据库。
- Mock像一个"导演助手"，它不仅要在场景中站位，还要记录你做了什么动作，最后回头检查你的行为对不对。
理解了这个基本区别，后面的内容就很好懂了。
2.2 三者关系图（文字版）
从抽象程度来看，Mock的抽象程度最高，它不需要知道业务逻辑，只需要记录行为。Fake的抽象程度最低，因为它需要实现一套简化版的业务逻辑。Stub介于两者之间，它只需要回答"我存了什么数据"这类问题。
三、Stub：只负责给出数据的占位符
3.1 Stub是什么
Stub（桩）是最简单的一种测试替身。它的唯一作用就是在被调用时返回一个预设好的值。Stub不关心调用逻辑，不记录调用次数，不做任何验证，它就是个"问答机器"。
举个生活中的例子，就像你问一个前台接待员"CEO在吗？"，不管什么时间、什么场合，她永远回答"在，请进"。这就是Stub。
3.2 完整示例演示
技术栈：Python + pytest
# 示例文件：test_stub_demo.py
# 技术栈：Python + pytest
# 用来说明 Stub 的基本用法
class UserRepository:
"""真实的用户仓库，需要连数据库"""
def __init__(self, db_connection):
self.db = db_connection
def find_user_by_email(self, email):
# 真实场景下会执行SQL查询
query = f"SELECT * FROM users WHERE email = '{email}'"
return self.db.execute(query)
class UserLoginService:
"""用户登录服务，依赖 UserRepository"""
def __init__(self, user_repository):
self.user_repo = user_repository
def login(self, email, password):
user = self.user_repo.find_user_by_email(email)
if user is None:
return {"success": False, "message": "用户不存在"}
if user["password"] == password:
return {"success": True, "user": user["name"]}
return {"success": False, "message": "密码错误"}
class StubUserRepository:
"""
Stub 版本的 UserRepository
不管传入什么 email，都返回固定的用户数据
它不会连数据库，不会做真实查询，
它的唯一任务就是返回我们预设好的值
"""
def find_user_by_email(self, email):
# 无论输入什么，都返回同一个用户
return {
"name": "张三",
"email": email, # 把传入的email原样返回，看起来更真实
"password": "123456"
}
# ====== 开始测试 ======
def test_login_success():
"""
测试登录成功场景
使用 Stub 来替代真实的数据库查询
"""
# 创建 Stub
stub_repo = StubUserRepository()
# 将 Stub 注入到被测服务中
login_service = UserLoginService(stub_repo)
# 执行登录
result = login_service.login("zhangsan@example.com", "123456")
# 验证结果
assert result["success"] == True
assert result["user"] == "张三"
def test_login_user_not_found():
"""
测试用户不存在的场景
这里需要另一个 Stub，返回 None
"""
class StubRepoReturnNone:
"""
另一个 Stub，专门用来模拟"找不到用户"的场景
"""
def find_user_by_email(self, email):
return None # 模拟数据库中不存在该用户
stub_repo = StubRepoReturnNone()
login_service = UserLoginService(stub_repo)
result = login_service.login("nobody@example.com", "123456")
assert result["success"] == False
assert result["message"] == "用户不存在"
def test_login_wrong_password():
"""
测试密码错误的场景
"""
stub_repo = StubUserRepository()
login_service = UserLoginService(stub_repo)
result = login_service.login("zhangsan@example.com", "wrong_password")
assert result["success"] == False
assert result["message"] == "密码错误"
3.3 Stub的特点总结
从上面的示例可以看出，Stub有几个很明显的特征。第一，它不需要任何框架支持，你用几行代码就能写一个。第二，它不能验证任何东西，你无法通过Stub知道被测代码有没有正确调用它的方法。第三，它很轻量，创建成本低，维护成本也低。
四、Fake：能跑通流程的简化替身
4.1 Fake是什么
Fake（假对象）是一种实现了接口但用简化方式实现逻辑的替身。它不像Stub那样只返回固定值，它内部有自己的逻辑，可以维护状态，甚至可以模拟一些真实的业务流程。
比如一个Fake数据库，它不需要真的连MySQL或PostgreSQL，而是用一个Python的字典来存数据。你往里插入一条记录，字典里就多一条；你查询一条记录，字典里就能找到。从外面看，它的行为很像真正的数据库，但实现方式完全不同。
4.2 完整示例演示
# 示例文件：test_fake_demo.py
# 技术栈：Python + pytest
# 用来说明 Fake 的用法和适用场景
class Order:
"""订单实体"""
def __init__(self, order_id, user_id, amount):
self.order_id = order_id
self.user_id = user_id
self.amount = amount
self.status = "pending" # 初始状态为待处理
class RealDatabase:
"""
真实的数据库类（这里简化展示）
在真实项目中会连接实际的数据库
"""
def __init__(self, connection_string):
self.conn = connection_string
def save_order(self, order):
# 真实实现会执行 INSERT SQL
pass
def find_order(self, order_id):
# 真实实现会执行 SELECT SQL
pass
def find_orders_by_user(self, user_id):
# 真实实现会执行 SELECT SQL
pass
class FakeDatabase:
"""
Fake 版本的数据库
用内存中的字典来模拟数据库的存储
它支持增删查改，但数据存在内存中，
测试结束后数据就消失了
适合用来测试那些需要"有状态"依赖的场景
"""
def __init__(self):
self._orders = {} # 模拟数据库表，用字典存储
self._users = {} # 模拟用户表
def save_order(self, order):
"""
模拟保存订单
真实数据库会写磁盘，这里只写内存字典
"""
self._orders[order.order_id] = order
# 注意：这里没有做任何参数校验
# 真实数据库可能会拒绝空值，Fake 不会
def find_order(self, order_id):
"""
模拟查询单条订单
"""
return self._orders.get(order_id)
def find_orders_by_user(self, user_id):
"""
模拟按用户查询所有订单
返回一个列表，模拟多条记录
"""
return [
order for order in self._orders.values()
if order.user_id == user_id
]
def count_orders(self):
"""
模拟统计订单数量
真实数据库用 COUNT(*)，这里用 len()
"""
return len(self._orders)
class OrderService:
"""订单服务，依赖数据库"""
def __init__(self, db):
self.db = db
def create_order(self, order_id, user_id, amount):
"""创建订单"""
order = Order(order_id, user_id, amount)
self.db.save_order(order)
return order
def get_user_order_history(self, user_id):
"""获取用户的历史订单"""
return self.db.find_orders_by_user(user_id)
def process_refund(self, order_id):
"""
处理退款
需要查询订单，修改状态，再保存
这个逻辑涉及多次数据库交互
用 Fake 来测试非常合适
"""
order = self.db.find_order(order_id)
if order is None:
return {"success": False, "message": "订单不存在"}
if order.status != "completed":
return {"success": False, "message": "订单状态不正确，无法退款"}
order.status = "refunded"
order.amount = 0
self.db.save_order(order)
return {"success": True, "message": "退款成功"}
# ====== 开始测试 ======
def test_create_order_and_query():
"""
测试创建订单后能查询到
Fake 的核心优势：数据是真实写入的（内存中），
后续的查询能读到前面写入的数据
这是 Stub 做不到的
"""
fake_db = FakeDatabase()
service = OrderService(fake_db)
# 创建订单
order = service.create_order("ORD001", "user_001", 299.00)
assert order.status == "pending"
# 查询刚创建的订单
found = fake_db.find_order("ORD001")
assert found is not None
assert found.amount == 299.00
def test_user_order_history():
"""
测试用户订单历史查询
需要数据库中有多条记录，Fake 可以很好地支持
"""
fake_db = FakeDatabase()
service = OrderService(fake_db)
# 为同一用户创建多个订单
service.create_order("ORD001", "user_001", 100.00)
service.create_order("ORD002", "user_001", 200.00)
service.create_order("ORD003", "user_002", 300.00) # 另一个用户
# 查询 user_001 的历史订单
history = service.get_user_order_history("user_001")
assert len(history) == 2
assert all(o.user_id == "user_001" for o in history)
# 查询 user_002 的历史订单
history2 = service.get_user_order_history("user_002")
assert len(history2) == 1
def test_refund_flow():
"""
测试完整的退款流程
这涉及：查订单 -> 验证状态 -> 修改 -> 保存
用 Fake 可以完整地模拟这个流程
"""
fake_db = FakeDatabase()
service = OrderService(fake_db)
# 先创建订单
order = service.create_order("ORD100", "user_010", 500.00)
order.status = "completed" # 手动把状态改成已完成（模拟支付完成）
# 执行退款
result = service.process_refund("ORD100")
assert result["success"] == True
assert result["message"] == "退款成功"
# 验证订单状态已被修改
updated = fake_db.find_order("ORD100")
assert updated.status == "refunded"
assert updated.amount == 0
def test_refund_nonexistent_order():
"""测试对不存在的订单退款"""
fake_db = FakeDatabase()
service = OrderService(fake_db)
result = service.process_refund("NOT_EXIST")
assert result["success"] == False
assert result["message"] == "订单不存在"
def test_refund_pending_order():
"""
测试对未完成订单退款应该失败
这个测试验证了业务逻辑的正确性
Fake 让状态流转变得可信
"""
fake_db = FakeDatabase()
service = OrderService(fake_db)
service.create_order("ORD200", "user_020", 300.00)
# 订单状态是 pending，不是 completed
result = service.process_refund("ORD200")
assert result["success"] == False
assert result["message"] == "订单状态不正确，无法退款"
4.3 Fake的适用场景
Fake最适合用在以下场景。第一，被测代码需要多次和依赖交互，并且后面的交互依赖前面的结果。比如你存了一条数据，然后去查它。第二，被测代码涉及状态流转。比如订单从"待处理"变成"已完成"再变成"已退款"。第三，你希望测试相对"集成"一些，不只是测单个函数。
4.4 Fake的局限性
Fake也有它的缺点。写一个Fake通常要写不少代码，因为它要模拟真实组件的大部分行为。如果你的依赖很复杂，写Fake的工作量可能不亚于写真实的实现。另外，Fake可能隐藏一些边界条件，比如Fake数据库不会抛出连接超时异常，而真实数据库会。
五、Mock：专注验证行为
5.1 Mock是什么
Mock（模拟对象）和前面两个最大的区别在于，Mock不仅要在测试中被调用，它还要验证被测代码是否以正确的方式调用了它。
具体来说，Mock可以验证：
- 某个方法是否被调用了
- 调用了多少次
- 用什么样的参数调用的
- 调用的顺序是否满足预期
Mock不做状态维护，不模拟业务逻辑，它纯粹关注"行为"。
5.2 完整示例演示
# 示例文件：test_mock_demo.py
# 技术栈：Python + pytest + unittest.mock
# 用来说明 Mock 的用法：行为验证
from unittest.mock import Mock, call
class PaymentGateway:
"""
真实的支付网关
会真的往支付宝/微信发消息扣钱
测试中绝对不能真的调它
"""
def charge(self, amount, card_token):
# 真实实现会调用第三方支付API
pass
def refund(self, transaction_id, amount):
# 真实实现会调用退款API
pass
def verify_card(self, card_token):
# 真实实现会验证卡片有效性
pass
class OrderPaymentService:
"""订单支付服务"""
def __init__(self, payment_gateway):
self.gateway = payment_gateway
def process_payment(self, order_id, amount, card_token):
"""
处理支付流程
预期行为：
1. 先验证卡片
2. 如果卡片有效，再执行扣款
3. 扣款成功后记录结果
"""
# 第一步：验证卡片
is_valid = self.gateway.verify_card(card_token)
if not is_valid:
return {"success": False, "message": "卡片验证失败"}
# 第二步：执行扣款
transaction_id = self.gateway.charge(amount, card_token)
return {
"success": True,
"transaction_id": transaction_id
}
def process_refund(self, transaction_id, amount):
"""
处理退款
预期行为：调用 gateway.refund 方法
"""
result = self.gateway.refund(transaction_id, amount)
return result
# ====== 开始测试 ======
def test_payment_success_flow():
"""
测试支付成功流程
使用 Mock 来验证支付网关被正确调用
"""
# 创建 Mock 对象
# Mock 对象的所有方法默认返回 None
# 我们需要配置它的返回值
mock_gateway = Mock()
# 配置 verify_card 返回 True（模拟卡片有效）
mock_gateway.verify_card.return_value = True
# 配置 charge 返回一个交易ID
mock_gateway.charge.return_value = "TXN_20240101_001"
# 注入 Mock
service = OrderPaymentService(mock_gateway)
# 执行支付
result = service.process_payment("ORD_001", 999.00, "card_token_abc")
# ====== 行为验证（这是 Mock 的核心价值） ======
# 验证 verify_card 被调用过一次
mock_gateway.verify_card.assert_called_once()
# 验证 verify_card 是用正确的参数调用的
mock_gateway.verify_card.assert_called_with("card_token_abc")
# 验证 charge 被调用过一次
mock_gateway.charge.assert_called_once()
# 验证 charge 的参数
mock_gateway.charge.assert_called_with(999.00, "card_token_abc")
# 验证返回值
assert result["success"] == True
assert result["transaction_id"] == "TXN_20240101_001"
def test_payment_card_invalid():
"""
测试卡片验证失败的场景
关键验证点：charge 不应该被调用
这是 Stub 无法验证的，因为 Stub 不记录调用行为
"""
mock_gateway = Mock()
mock_gateway.verify_card.return_value = False
service = OrderPaymentService(mock_gateway)
result = service.process_payment("ORD_002", 500.00, "bad_card")
# 验证 verify_card 被调用过
mock_gateway.verify_card.assert_called_once()
# 关键：验证 charge 没有被调用！
# 因为卡片无效，不应该执行扣款
mock_gateway.charge.assert_not_called()
assert result["success"] == False
assert result["message"] == "卡片验证失败"
def test_refund_calls_gateway():
"""
测试退款是否正确调用了支付网关
"""
mock_gateway = Mock()
mock_gateway.refund.return_value = {"status": "refunded", "amount": 200.00}
service = OrderPaymentService(mock_gateway)
result = service.process_refund("TXN_001", 200.00)
# 验证 refund 被调用，且参数正确
mock_gateway.refund.assert_called_once_with("TXN_001", 200.00)
assert result["status"] == "refunded"
def test_payment_verify_then_charge_order():
"""
测试调用顺序：必须先验证卡片，再执行扣款
如果顺序反了，说明代码逻辑有问题
assert_has_calls 可以验证调用顺序
"""
mock_gateway = Mock()
mock_gateway.verify_card.return_value = True
mock_gateway.charge.return_value = "TXN_002"
service = OrderPaymentService(mock_gateway)
service.process_payment("ORD_003", 100.00, "card_xyz")
# 验证调用顺序
expected_calls = [
call.verify_card("card_xyz"), # 第一步：验证卡片
call.charge(100.00, "card_xyz") # 第二步：执行扣款
]
mock_gateway.assert_has_calls(expected_calls, any_order=False)
def test_refund_gateway_error():
"""
测试支付网关返回错误时服务的表现
"""
mock_gateway = Mock()
mock_gateway.refund.return_value = {"status": "failed", "error": "余额不足"}
service = OrderPaymentService(mock_gateway)
result = service.process_refund("TXN_003", 9999.00)
mock_gateway.refund.assert_called_once()
assert result["status"] == "failed"
5.3 Mock能验证什么而Stub不能
这个问题的核心在于"验证行为"和"提供数据"的区别。Stub只能说"我返回了一个值"，但Mock能说"你确实用这个参数调了我三次"。当测试的焦点是"被测代码有没有正确地使用依赖"时，Mock是唯一的选择。
六、三者综合对比与选型指南
6.1 综合对比表
下面用文字梳理一下三者的核心区别，帮助你在实际工作中快速做选择。
Stub的特点：只返回预设数据，不验证调用，不维护状态。写起来最简单，一个方法几行代码搞定。适合用来替代配置读取器、简单的数据提供者。
Fake的特点：有内部逻辑和状态，可以模拟真实组件的大部分行为。写起来最费事，可能要写几十行甚至上百行代码。适合用来替代数据库、缓存、文件系统等"有状态"的组件。
Mock的特点：可以预设返回值，同时能验证方法被如何调用。需要借助框架（如unittest.mock），语法相对复杂。适合用来验证行为，比如"发送了短信"、"记录了日志"、"调用了外部API"。
6.2 选型决策树
当你面对一个需要测试替身的场景时，可以按以下思路来选：
第一步，问自己：我需不需要验证被测代码对依赖的调用行为？如果需要，选Mock。
第二步，如果不需要验证行为，问自己：被测代码是否会和依赖进行多次交互，且后续交互依赖前面的结果？如果是，选Fake。
第三步，如果上面的答案都是"否"，那只需要一个简单的数据提供者，选Stub就足够了。
6.3 综合示例：三者配合使用
# 示例文件：test_combined_demo.py
# 技术栈：Python + pytest + unittest.mock
# 展示 Stub、Fake、Mock 在一个复杂场景中的配合使用
from unittest.mock import Mock
# ====== Stub：提供配置数据 ======
class ConfigStub:
"""
Stub：替代配置文件读取
只返回我们设定好的配置值
不关心怎么读的，只关心返回什么
"""
def get(self, key):
config = {
"max_order_amount": 10000.00,
"min_order_amount": 1.00,
"payment_timeout_seconds": 30
}
return config.get(key)
# ====== Fake：模拟订单存储 ======
class FakeOrderStore:
"""
Fake：替代真实的订单数据库
用内存字典存储订单，支持增删查
可以维护状态，模拟真实DB的行为
"""
def __init__(self):
self._orders = {}
def save(self, order):
self._orders[order["order_id"]] = order
def find_by_id(self, order_id):
return self._orders.get(order_id)
def find_all(self):
return list(self._orders.values())
def delete(self, order_id):
self._orders.pop(order_id, None)
# ====== Mock：验证通知发送行为 ======
class NotificationSender:
"""真实的通知发送器，会发手机短信或推送"""
def send_sms(self, phone, message):
pass
def send_push(self, user_id, title, body):
pass
# ====== 被测服务 ======
class CompleteOrderService:
"""
完整的订单创建服务
依赖三种不同类型的组件：
- ConfigStub：读配置（Stub场景）
- FakeOrderStore：存订单（Fake场景）
- NotificationSender：发通知（Mock场景）
"""
def __init__(self, config, order_store, notification):
self.config = config
self.order_store = order_store
self.notification = notification
def create_order(self, order_id, user_id, phone, amount, items):
"""
创建订单的完整流程：
1. 从配置中读取金额上限，做校验（使用 Stub）
2. 构建订单对象，存入存储（使用 Fake）
3. 发送通知给用户（使用 Mock 来验证）
"""
# 步骤1：使用配置做金额校验
max_amount = self.config.get("max_order_amount")
if amount > max_amount:
return {"success": False, "message": "订单金额超出上限"}
min_amount = self.config.get("min_order_amount")
if amount < min_amount:
return {"success": False, "message": "订单金额低于最低限额"}
# 步骤2：构建并保存订单
order = {
"order_id": order_id,
"user_id": user_id,
"amount": amount,
"items": items,
"status": "created"
}
self.order_store.save(order)
# 步骤3：发送短信通知
message = f"订单 {order_id} 创建成功，金额 ¥{amount:.2f}"
self.notification.send_sms(phone, message)
return {"success": True, "order_id": order_id}
# ====== 测试代码：三种替身配合使用 ======
def test_create_order_all_green():
"""
完整测试：正常创建订单
同时用到 Stub（读配置）、Fake（存数据）、Mock（验行为）
"""
# 准备 Stub：配置
config = ConfigStub()
# 准备 Fake：订单存储
order_store = FakeOrderStore()
# 准备 Mock：通知发送
mock_notification = Mock()
# 组装被测服务
service = CompleteOrderService(config, order_store, mock_notification)
# 执行创建订单
result = service.create_order(
order_id="ORD_FULL_001",
user_id="user_alpha",
phone="13800138000",
amount=299.00,
items=["苹果 x2", "香蕉 x3"]
)
# 验证结果
assert result["success"] == True
assert result["order_id"] == "ORD_FULL_001"
# 验证 Fake 中确实存入了订单
stored = order_store.find_by_id("ORD_FULL_001")
assert stored is not None
assert stored["amount"] == 299.00
assert stored["status"] == "created"
# 验证 Mock：通知确实被发送了
mock_notification.send_sms.assert_called_once()
mock_notification.send_sms.assert_called_with(
"13800138000",
"订单 ORD_FULL_001 创建成功，金额 ¥299.00"
)
def test_create_order_amount_exceeds_limit():
"""
测试金额超出上限的场景
通过 Stub 控制配置值，验证业务规则
"""
class ConfigStubHighLimit:
"""Stub 变体：设置一个较低的上限"""
def get(self, key):
if key == "max_order_amount":
return 500.00 # 故意设低
return 1.00
config = ConfigStubHighLimit()
order_store = FakeOrderStore()
mock_notification = Mock()
service = CompleteOrderService(config, order_store, mock_notification)
result = service.create_order(
order_id="ORD_EXCEED",
user_id="user_beta",
phone="13900139000",
amount=600.00, # 超过 500 的上限
items=["大件商品"]
)
assert result["success"] == False
assert result["message"] == "订单金额超出上限"
# 验证没有存入订单
assert order_store.find_by_id("ORD_EXCEED") is None
# 验证没有发送通知
mock_notification.send_sms.assert_not_called()
def test_create_order_stored_correctly():
"""
重点测试 Fake 的状态管理能力
创建多个订单后，验证存储中所有订单的数据
"""
config = ConfigStub()
order_store = FakeOrderStore()
mock_notification = Mock()
service = CompleteOrderService(config, order_store, mock_notification)
# 连续创建三个订单
service.create_order("O1", "u1", "13800000001", 100.00, ["A"])
service.create_order("O2", "u1", "13800000002", 200.00, ["B"])
service.create_order("O3", "u2", "13800000003", 300.00, ["C"])
# 用 Fake 验证存储的完整性
all_orders = order_store.find_all()
assert len(all_orders) == 3
total_amount = sum(o["amount"] for o in all_orders)
assert total_amount == 600.00
七、技术优缺点详细分析
7.1 Stub的优缺点
Stub最大的优点是简单。不需要任何框架，不需要学习额外语法，用几行Python代码就能搭一个。维护成本也极低，改了预期返回值改一行就行。它非常适合测试那些只涉及"拿到某个数据"的逻辑分支。
但Stub的缺点也很明显。它不能验证任何行为，你无法知道被测代码有没有调用它、用什么样的参数调用的、调了多少次。如果你选错了Stub，以为验证了行为实际上并没有验证，测试结果会给你一种虚假的安全感。另外，Stub是"无状态"的，如果测试中需要依赖产生状态变化，Stub就无能为力了。
7.2 Fake的优缺点
Fake最大的优点是可信度高。因为Fake内部实现了真实组件的大部分逻辑，通过Fake的测试通常意味着被测代码在集成真实组件时也不太会出问题。Fake能维护状态，能支持多次交互，能模拟复杂的数据流转。对于数据库、文件系统这类"有状态"的依赖，Fake是最佳选择。
但Fake的代价是代码量大。写一个功能完备的Fake可能要花上半天时间，后续维护也要跟着真实组件同步修改。而且Fake可能掩盖一些边界情况，比如Fake不会遇到"数据库连接超时"这种网络问题，而真实环境会。如果过度依赖Fake，你可能发现测试全绿，但上线后出了问题。
7.3 Mock的优缺点
Mock最大的价值在于行为验证。它能告诉你"被测代码确实按照预期和依赖进行了交互"。这对于测试复杂业务流程尤其重要，比如支付流程中"先验证再扣款"的顺序不能错。Mock配合强大的框架（如unittest.mock、Mockito等），可以用非常简洁的代码完成复杂的验证。
但Mock的缺点是容易过度使用。一旦你开始用Mock，可能会不自觉地把所有依赖都Mock掉，最后测试代码全是断言"某方法被调用了"，却没有验证任何实际结果。这种测试叫做"Mock过度"，测试看起来很完善，但代码改了实现细节就全红了，失去了测试的价值。另外，Mock对象通常不支持属性链式调用等复杂场景，某些情况需要额外配置。
八、注意事项与常见误区
8.1 误区一：把所有替身都叫Mock
这是最常见的混淆。很多人说"我Mock了数据库"，但实际上用的是Fake。这个混淆本身不致命，但如果连自己都不清楚用了什么，就很难判断测试覆盖到了什么程度。建议团队内部约定术语，明确区分。
8.2 误区二：Mock过度导致测试脆弱
如果一个测试中出现了大量的assert_called，说明你可能过度依赖Mock了。理想的做法是尽量少验证行为，多验证结果。比如你测一个发送邮件的服务，与其验证"SMTP.send被调用了"，不如验证"用户的收件箱中多了一封邮件"。后者对实现细节的耦合更小。
8.3 误区三：用Fake掩盖设计问题
有时候你发现写一个Fake特别费劲，这往往说明你的依赖设计得太重了。如果你需要模拟一个对象的几十个方法，考虑是否可以用接口隔离原则，把依赖拆得更细。
8.4 误区四：替身行为不一致于真实组件
无论Stub、Fake还是Mock，如果它们的行为和真实组件偏差太大，测试结果就失去了参考价值。比如在测试中Mock返回成功，但真实组件在同样输入下会抛出异常，那你的测试就是在骗自己。建议定期检查替身行为是否与真实实现保持一致。
8.5 误区五：忽视测试隔离性
即使是使用替身，测试之间也可能产生干扰。比如两个测试共用同一个Fake数据库实例，前一个测试写入的数据会影响后一个测试。解决方案是每个测试都创建新的替身实例，确保测试彼此独立。
九、文章总结
在单元测试中选择正确的测试替身，是写出可信测试的基础。Stub、Fake和Mock三者各有千秋，理解它们的本质差异才能做到游刃有余。
Stub是"数据提供者"，它只负责在需要的时候吐出预设好的值，简单轻量，适合替代配置读取、简单数据获取这类场景。它的价值在于让测试不依赖外部环境，但它的局限在于无法验证任何调用行为。
Fake是"行为模拟器"，它用简化实现来模拟真实组件的行为，能维护状态、支持多次交互。对于数据库、缓存这类需要状态流转的依赖，Fake是最合适的选择。它的代价是编写和维护成本较高，但换来的是更接近真实场景的测试结果。
Mock是"行为验证器"，它不仅能返回预设值，还能记录并验证被测代码的调用行为。当你需要确保"某方法被用正确的参数调用"时，Mock是唯一的选择。但要注意不要过度使用，避免测试变成单纯的"行为断言堆砌"。
实际项目中，这三个替身往往是配合使用的。同一个测试中，你可以用Stub读配置、用Fake存数据、用Mock验证外部调用。关键在于明确每个替身的职责，让它们各司其职，不要混淆。
选择替身的黄金法则是：用最简单能满足需求的那一个。如果Stub够了就别用Mock，如果不需要验证行为就别引入Mock框架。保持测试的简洁性，才能让你的测试套件易于维护、运行快速、结果可信。
评论
围绕“单元测试中Stub、Fake与Mock：深入辨析测试替身的具体差异与适用场景，避免隔离策略选择失误导致误导性结论，保障测试独立性。”参与讨论