4、Stub模式入门：用简单结构体实现Stub，硬编码返回值替换真实依赖

在测试金字塔的底层，单元测试要求我们隔离被测试单元。当被测试函数依赖外部服务、数据库或复杂计算模块时，Stub（桩）是最轻量的替身技术。本章将带你从零实现一个Go结构体Stub，理解其核心思想：用硬编码返回值替换真实依赖。

4.1 为什么需要Stub？——真实依赖的测试困境

假设我们有一个OrderService，它依赖InventoryClient查询库存。真实客户端会发起HTTP请求，导致测试变慢、不稳定且依赖外部环境。

4.2 Stub模式的结构：接口 + 结构体 + 硬编码

Go语言中实现Stub的标准三步法：

1. 定义接口：抽取真实依赖的行为契约。
2. 创建Stub结构体：实现该接口，方法内部直接返回预设值。
3. 注入Stub：在测试中替换真实依赖。

4.3 实战：为订单服务编写InventoryStub

我们通过一个完整示例，展示从接口定义到测试验证的全过程。

步骤1：定义接口（真实项目中的契约）

// inventory.go (真实项目)
type InventoryChecker interface {
    CheckStock(sku string) (bool, error)
}

步骤2：编写Stub结构体（测试文件内）

// inventory_stub.go (测试文件)
type InventoryStub struct {
    // 硬编码返回值
    StockAvailable bool
    CheckErr       error
}

func (s *InventoryStub) CheckStock(sku string) (bool, error) {
    // 忽略输入参数，直接返回预设值
    return s.StockAvailable, s.CheckErr
}

步骤3：在测试中注入Stub

// order_service_test.go
func TestCreateOrder_StockAvailable(t *testing.T) {
    // 准备Stub
    stub := &InventoryStub{
        StockAvailable: true,
        CheckErr:       nil,
    }

    // 注入Stub到被测试对象
    svc := NewOrderService(stub)

    // 执行测试
    err := svc.CreateOrder("SKU-001", 2)
    if err != nil {
        t.Errorf("期望无错误，得到: %v", err)
    }
}

func TestCreateOrder_StockUnavailable(t *testing.T) {
    stub := &InventoryStub{
        StockAvailable: false,
        CheckErr:       nil,
    }

    svc := NewOrderService(stub)
    err := svc.CreateOrder("SKU-001", 2)
    if err == nil {
        t.Error("期望库存不足错误，但没有得到")
    }
}

4.4 Stub的变体：多场景预设

一个Stub结构体可以通过字段组合，覆盖多个测试场景：

4.5 Stub vs Mock：一张表看清区别

4.6 使用Stub的常见陷阱

• 陷阱1：Stub中引入条件逻辑——如果Stub根据输入参数返回不同值，它就变成了Fake（伪对象），增加了维护成本。保持Stub的“无脑”特性。
• 陷阱2：Stub覆盖所有路径——Stub只覆盖测试关心的路径。不要试图用Stub模拟所有异常情况，那会导致Stub本身需要测试。
• 陷阱3：在Stub中记录调用——一旦在Stub中添加callCount或lastArgs，它就变成了Spy（间谍），不再是纯粹的Stub。保持职责单一。

4.7 小结：Stub模式的核心要点