从手写初始化到 pytest fixture：让 Python 测试既干净、可复用，又能驾驭异步并发

当测试测到了"假的世界"：Mock 的价值、风险与正确用法

在软件开发里，测试像是一张安全网。我们写单元测试、集成测试、端到端测试，希望每一次重构、每一次上线前，都能更有底气地说："这次改动没有把系统弄坏。"

但很多团队会遇到一个尴尬场景：

测试全绿，线上全挂。

单测覆盖率 90% 以上，生产环境却因为一个真实依赖的变化崩了。

查到最后发现：测试里所有外部依赖都被 mock 掉了。

这就是 Mock 最经典的风险：你以为你测试了系统，实际上你只是测试了自己想象中的系统。

这篇文章就聊一个很实用的问题：

Mock 的价值与风险是什么？什么叫"测到了假的世界"？我们该如何正确使用 Mock？

---

一、Mock 是什么：把真实依赖替换成"可控替身"

Mock，本质上是一种测试替身。它用一个假的对象、函数或服务，代替真实依赖。

比如你的业务逻辑需要调用支付接口：

class PaymentClient:
    def charge(self, user_id: int, amount: int) -> bool:
        # 调用真实支付服务
        ...

业务代码：

class OrderService:
    def __init__(self, payment_client: PaymentClient):
        self.payment_client = payment_client

    def pay_order(self, user_id: int, amount: int) -> str:
        success = self.payment_client.charge(user_id, amount)

        if success:
            return "PAID"
        return "FAILED"

测试时，我们不希望真的扣钱，于是 mock 掉支付接口：

from unittest.mock import Mock

def test_pay_order_success():
    payment_client = Mock()
    payment_client.charge.return_value = True

    service = OrderService(payment_client)

    result = service.pay_order(user_id=1, amount=100)

    assert result == "PAID"
    payment_client.charge.assert_called_once_with(1, 100)

这个测试的好处很明显：

它快、稳定、可控，而且不会真的调用第三方支付服务。

这就是 Mock 的核心价值：让测试从不可控的外部世界中抽离出来，专注验证当前代码的行为。

---

二、Mock 的价值：为什么它不可或缺？

Mock 并不是坏东西。恰恰相反，在现代软件测试中，它非常重要。

1. 隔离外部依赖，让单元测试更稳定

真实依赖往往不稳定：

数据库可能连接失败，网络可能超时，第三方 API 可能限流，文件系统可能权限不足，消息队列可能堆积。

如果每个单元测试都依赖真实外部系统，那么测试就会变慢、变脆弱，还容易因为环境问题误报失败。

比如测试一个发送邮件的函数：

def send_welcome_email(email_client, user_email):
    email_client.send(
        to=user_email,
        subject="Welcome",
        body="Thanks for joining us!"
    )

测试时不需要真的发邮件：

def test_send_welcome_email():
    email_client = Mock()

    send_welcome_email(email_client, "alice@example.com")

    email_client.send.assert_called_once_with(
        to="alice@example.com",
        subject="Welcome",
        body="Thanks for joining us!"
    )

这里 Mock 的意义是：我只关心业务代码是否正确调用了邮件客户端，而不是邮件服务本身是否正常。

---

2. 模拟异常场景，覆盖真实环境中难以触发的分支

真实系统里，有些异常很难稳定复现。例如支付超时、Redis 断连、接口返回 500、数据库死锁。

Mock 可以帮助我们主动制造这些场景。

def get_user_profile(user_client, user_id):
    try:
        return user_client.get_user(user_id)
    except TimeoutError:
        return {"id": user_id, "name": "Unknown"}

测试超时分支：

def test_get_user_profile_timeout():
    user_client = Mock()
    user_client.get_user.side_effect = TimeoutError

    result = get_user_profile(user_client, 42)

    assert result == {"id": 42, "name": "Unknown"}

如果没有 Mock，这种异常分支可能永远测不到。

---

3. 提升测试速度，降低反馈成本

优秀的工程团队追求快速反馈。代码一改，几秒钟内知道有没有破坏核心逻辑，这是非常宝贵的。

Mock 可以让大量单元测试在本地快速完成，而不必启动完整系统、连接数据库、部署服务或等待网络返回。

对于持续集成来说，这一点尤其重要。

---

4. 驱动更好的设计

当一个模块很难 mock，往往说明它的依赖没有被清晰地抽象出来。

比如下面这种代码就不好测：

def create_order(user_id, amount):
    payment_client = PaymentClient()
    result = payment_client.charge(user_id, amount)
    return result

因为 PaymentClient 在函数内部直接创建，测试时不好替换。

更好的设计是依赖注入：

def create_order(payment_client, user_id, amount):
    result = payment_client.charge(user_id, amount)
    return result

这样测试更容易，代码也更灵活。

Mock 在这里倒逼我们把依赖关系显式化，让模块边界更加清晰。

---

三、Mock 的风险：测试全绿，生产却挂了

Mock 最大的问题是：它可能让测试脱离真实世界。

回到开头的场景：

你的测试全是 mock，改真实依赖后测试依然全绿，但生产挂了。

这通常不是测试没有写，而是测试写到了一个"假的世界"。

---

四、什么叫"测到了假的世界"？

"测到了假的世界"指的是：

测试验证的是 mock 出来的行为，而不是真实系统会发生的行为。

也就是说，你的测试没有证明代码能和真实依赖正确协作，只证明了它能和你自己伪造的依赖协作。

举个例子。

假设真实支付接口返回的是：

{
  "status": "success",
  "transaction_id": "abc123"
}

你的代码：

def pay(payment_client, user_id, amount):
    response = payment_client.charge(user_id, amount)

    if response["status"] == "success":
        return response["transaction_id"]

    raise Exception("payment failed")

测试里你 mock 了一个返回值：

def test_pay_success():
    payment_client = Mock()
    payment_client.charge.return_value = {
        "status": "success",
        "transaction_id": "abc123"
    }

    result = pay(payment_client, 1, 100)

    assert result == "abc123"

这个测试看起来没问题。

但如果真实接口升级后返回变成：

{
  "code": 0,
  "data": {
    "transaction_id": "abc123"
  }
}

你的测试仍然全绿，因为 mock 还在返回旧格式。

但生产环境会直接报错：

KeyError: 'status'

这就是"测到了假的世界"。

测试验证了你脑海中的接口，却没有验证真实接口。

---

五、Mock 滥用的几个典型信号

1. 测试里 mock 了太多层

如果一个测试里出现大量 mock：

db = Mock()
cache = Mock()
logger = Mock()
payment = Mock()
user_client = Mock()
coupon_client = Mock()
message_queue = Mock()

你要警惕：这个测试可能已经不再验证真实业务流程，而是在搭一个虚构舞台。

Mock 越多，测试越像剧本。剧本当然可以完美，但生产环境不是按剧本演的。

---

2. 测试只关心"调用了什么"，不关心"结果是否正确"

比如：

def test_create_order():
    repo = Mock()
    service = OrderService(repo)

    service.create_order(user_id=1, amount=100)

    repo.save.assert_called_once()

这个测试只证明了 save 被调用过，但没有证明保存的数据是正确的。

更好的测试应该检查保存内容：

def test_create_order():
    repo = Mock()
    service = OrderService(repo)

    service.create_order(user_id=1, amount=100)

    saved_order = repo.save.call_args[0][0]

    assert saved_order.user_id == 1
    assert saved_order.amount == 100
    assert saved_order.status == "CREATED"

不过进一步思考：如果保存逻辑很关键，也许你不应该 mock repo，而应该使用测试数据库或内存实现。

---

3. Mock 的返回值与真实依赖不一致

这是最危险的问题之一。

user_client.get_user.return_value = {
    "id": 1,
    "name": "Alice"
}

但真实接口可能返回：

{
  "user_id": 1,
  "profile": {
    "display_name": "Alice"
  }
}

测试中的假数据越随意，测试越不可信。

---

4. Mock 掩盖了序列化、网络、权限、事务等真实问题

很多问题只会在真实集成时暴露：

请求字段名不对，JSON 序列化失败，数据库字段长度超限，权限不足，事务没提交，时区格式错误，分页参数不兼容，超时配置不合理。

这些问题，单纯 mock 是测不出来的。

---

六、如何正确使用 Mock？

核心原则是：

Mock 边界之外的东西，不 mock 你真正想验证的行为。

换句话说，Mock 应该用来隔离不稳定、昂贵、不可控的外部依赖，而不是逃避真实业务逻辑的验证。

---

七、实战原则一：只 mock 外部边界，不 mock 核心业务

推荐 mock 的对象：

第三方 API、邮件服务、短信服务、支付网关、系统时间、随机数、网络请求、昂贵计算、外部文件服务。

不推荐轻易 mock 的对象：

核心领域模型、核心业务规则、内部纯函数、数据转换逻辑、你真正想验证的模块。

例如订单折扣计算：

def calculate_price(amount, vip_level):
    if vip_level == "gold":
        return amount * 0.8
    if vip_level == "silver":
        return amount * 0.9
    return amount

这种函数不需要 mock，直接测：

def test_calculate_price_for_gold_user():
    assert calculate_price(100, "gold") == 80

业务规则越核心，越应该用真实代码测。

---

八、实战原则二：使用 Fake 替代过度 Mock

测试替身不只有 Mock，还有 Fake、Stub、Spy。

Mock 强调验证交互，例如"某个方法是否被调用"。

Fake 则是一个可工作的简化实现。

比如订单仓储：

class FakeOrderRepository:
    def __init__(self):
        self.orders = []

    def save(self, order):
        self.orders.append(order)

    def list_all(self):
        return self.orders

测试：

def test_create_order_with_fake_repo():
    repo = FakeOrderRepository()
    service = OrderService(repo)

    service.create_order(user_id=1, amount=100)

    orders = repo.list_all()

    assert len(orders) == 1
    assert orders[0].user_id == 1
    assert orders[0].amount == 100

Fake 的好处是，它比 Mock 更接近真实行为，也更少依赖"调用细节"。

Mock 经常让测试锁死内部实现，而 Fake 更关注最终状态。

---

九、实战原则三：为真实依赖补充集成测试

不要指望单元测试解决所有问题。

更健康的测试结构通常是：

大量单元测试：验证核心逻辑，速度快
适量集成测试：验证模块与真实依赖是否协作正常
少量端到端测试：验证关键业务链路

例如支付系统：

单元测试可以 mock 支付客户端，验证支付成功、失败、超时后的业务处理。

但你还需要集成测试确认：

真实请求字段是否正确，签名算法是否符合要求，接口返回格式是否匹配，错误码是否被正确解析，超时和重试是否生效。

示例：

def test_parse_real_payment_response():
    response = {
        "code": 0,
        "data": {
            "transaction_id": "tx_123",
            "status": "SUCCESS"
        }
    }

    result = parse_payment_response(response)

    assert result.transaction_id == "tx_123"
    assert result.success is True

如果不能直接调用真实第三方服务，也可以使用它们提供的 sandbox 环境，或者用契约测试来保证接口格式一致。

---

十、实战原则四：用契约测试防止 Mock 失真

Mock 最大的问题是容易和真实依赖脱节。

契约测试的作用是：确保消费者和提供者对接口的理解一致。

比如你的系统依赖用户服务：

def get_username(user_client, user_id):
    user = user_client.get_user(user_id)
    return user["name"]

你在测试中 mock：

user_client.get_user.return_value = {
    "id": 1,
    "name": "Alice"
}

但真实用户服务是否真的返回 name 字段？

契约测试应该验证真实接口或接口 schema：

def test_user_api_contract(real_user_client):
    user = real_user_client.get_user(1)

    assert "id" in user
    assert "name" in user
    assert isinstance(user["id"], int)
    assert isinstance(user["name"], str)

这类测试不一定每次本地都跑，但应该在 CI 或发布流程中定期运行。

---

十一、实战原则五：Mock 数据要来自真实样本

不要随手编 mock 数据。

坏例子：

payment_client.charge.return_value = {"ok": True}

如果真实接口从来不返回 ok 字段，这个测试没有意义。

更好的方式是保存真实响应样本：

REAL_PAYMENT_SUCCESS_RESPONSE = {
    "code": 0,
    "message": "success",
    "data": {
        "transaction_id": "tx_20250101_001",
        "status": "SUCCESS",
        "paid_at": "2025-01-01T10:00:00Z"
    }
}

然后测试基于真实样本：

def test_handle_payment_success():
    payment_client = Mock()
    payment_client.charge.return_value = REAL_PAYMENT_SUCCESS_RESPONSE

    result = handle_payment(payment_client, user_id=1, amount=100)

    assert result.status == "PAID"
    assert result.transaction_id == "tx_20250101_001"

真实样本最好来自文档、sandbox、生产脱敏日志或契约文件。

---

十二、实战原则六：不要 mock 自己不理解的东西

这是一个很朴素但非常重要的原则。

如果你不清楚真实依赖的行为，就不要急着 mock 它。否则你 mock 出来的不是依赖，而是幻想。

比如 Redis 的 setnx、数据库事务、消息队列 ack 机制、HTTP 重试语义，这些都包含很多细节。

如果你只是这样写：

redis_client.setnx.return_value = True

你可能完全忽略了 key 过期、并发竞争、网络失败、序列化格式等问题。

对复杂依赖，优先考虑：

使用真实测试容器，使用本地模拟服务，使用官方 sandbox，使用更高层级的集成测试。

---

十三、一个完整案例：Mock 让测试全绿，真实依赖却变了

假设我们有一个发优惠券的功能：

def issue_coupon(coupon_client, user_id):
    response = coupon_client.create_coupon(user_id)

    if response["success"]:
        return response["coupon_id"]

    raise Exception("coupon issue failed")

单元测试：

def test_issue_coupon_success():
    coupon_client = Mock()
    coupon_client.create_coupon.return_value = {
        "success": True,
        "coupon_id": "c_001"
    }

    result = issue_coupon(coupon_client, 1)

    assert result == "c_001"

后来优惠券服务升级，真实返回变成：

{
  "code": 200,
  "data": {
    "id": "c_001"
  }
}

测试依然全绿，但生产报错：

KeyError: 'success'

正确做法是把响应解析逻辑单独抽出来，并用真实样本测试：

class CouponIssueError(Exception):
    pass


def parse_coupon_response(response):
    if response.get("code") == 200:
        return response["data"]["id"]

    raise CouponIssueError(response.get("message", "unknown error"))


def issue_coupon(coupon_client, user_id):
    response = coupon_client.create_coupon(user_id)
    return parse_coupon_response(response)

测试解析逻辑：

def test_parse_coupon_response_success():
    response = {
        "code": 200,
        "data": {
            "id": "c_001"
        }
    }

    assert parse_coupon_response(response) == "c_001"

再测试业务调用：

def test_issue_coupon_success():
    coupon_client = Mock()
    coupon_client.create_coupon.return_value = {
        "code": 200,
        "data": {
            "id": "c_001"
        }
    }

    result = issue_coupon(coupon_client, 1)

    assert result == "c_001"
    coupon_client.create_coupon.assert_called_once_with(1)

如果条件允许，再补一个集成测试：

def test_coupon_client_contract(real_coupon_client):
    response = real_coupon_client.create_coupon(user_id=1)

    assert "code" in response
    assert "data" in response
    assert "id" in response["data"]

这样，Mock 负责隔离外部服务，契约测试负责防止接口失真，单元测试负责验证核心逻辑。

---

十四、Mock 使用清单：写测试前先问自己这几个问题

每次你准备使用 Mock，可以问自己：

1. 我 mock 的是外部依赖，还是核心业务逻辑？
2. 这个 mock 的返回值是否来自真实样本？
3. 如果真实依赖接口变了，这个测试会失败吗？
4. 我是在验证行为结果，还是只是在验证调用细节？
5. 这个场景是否更适合用 Fake、测试数据库或集成测试？
6. Mock 是否让测试过度绑定内部实现？
7. 有没有至少一条测试覆盖真实依赖或契约？

如果这些问题你答不上来，测试很可能正在走向"假的世界"。

---

十五、好的测试不是全 mock，也不是零 mock

有些人看到 Mock 的风险，就走向另一个极端：完全不用 Mock。

这也不现实。

完全不用 Mock，测试会变慢、变脆弱、难以覆盖异常分支。尤其在涉及支付、短信、邮件、外部 API 的场景里，Mock 仍然是必要工具。

真正成熟的做法不是拒绝 Mock，而是分层使用：

纯业务逻辑：直接测真实代码
外部依赖边界：谨慎 mock
复杂依赖行为：用 Fake 或测试容器
跨服务接口：用契约测试
关键用户路径：用端到端测试

Mock 是手术刀，不是遮羞布。

它应该帮助你隔离复杂性，而不是掩盖复杂性。

---

十六、总结：Mock 的价值在隔离，风险在失真

Mock 的价值很清晰：

它让测试更快、更稳定、更可控；它能模拟异常场景；它能推动更清晰的模块设计。

但 Mock 的风险也同样明显：

它可能让测试远离真实依赖；它可能制造虚假的安全感；它可能让你"测试通过"，却没有真正验证系统能在生产环境中运行。

所谓"测到了假的世界"，就是：

测试验证的是你假设中的依赖行为，而不是系统真实会面对的依赖行为。

避免这个问题的关键，不是少写测试，而是写对测试。

好的测试应该既有速度，也有真实性；既能保护局部逻辑，也能覆盖关键集成；既能让开发者快速反馈，也能让团队对上线有信心。

最后送给每个写测试的人一句话：

不要为了让测试变绿而写 Mock，要为了让系统更可靠而写测试。

当你下一次看到满屏绿色测试结果时，不妨多问一句：

它们真的测到了真实世界吗？