Mock与Stub是否属于实现细节？TDD测试场景下的疑问

你的疑问切中了TDD实践里的核心边界问题——核心结论是：Mock/Stub本身不是实现细节，关键是你Mock的是「依赖的契约」还是「被测服务的内部实现细节」。

1. 区分「依赖契约」和「实现细节」 #

TDD强调的「使用者视角」，本质是聚焦被测实体对外承诺的行为，而非它内部的执行路径。以PlaceOrder为例：

• 它对外的核心承诺是：「接收下单请求，校验用户余额后返回下单成功/失败」——这是使用者唯一需要关心的。
• 而「到底是实时调用信用卡服务，还是用缓存的额度数据」，这才是PlaceOrder的内部实现细节，使用者完全不需要在意。

但这里有个关键：PlaceOrder要完成余额校验，必须依赖一个「能提供余额校验能力」的实体。这个实体的公共接口契约（比如「输入用户ID，返回余额是否充足」），是PlaceOrder业务逻辑的必要组成部分，不属于实现细节——没有这个契约，PlaceOrder根本无法履行它对外的核心承诺。

2. 给PlaceOrder写测试的合理姿势 #

根据测试层级不同，有两种贴合TDD思路的方式：

• 黑盒集成测试（纯使用者视角）：
  不用Mock，直接对接信用卡服务的测试环境（或轻量模拟服务）。你只需要输入下单请求，验证最终的下单结果（成功/失败），完全不关心PlaceOrder内部是调服务还是读缓存。这种测试直接验证PlaceOrder的整体对外行为，完全符合使用者视角。
• 单元测试（隔离被测服务逻辑）：
  定义一个抽象的BalanceChecker接口（比如包含hasSufficientBalance(userId)方法），让PlaceOrder依赖这个接口，而非具体的信用卡服务或缓存。测试时用Mock实现这个接口，预设返回值（比如true/false），验证PlaceOrder的核心逻辑是否正确：

  // 示例：Java单元测试用Mock
  @Test
  void placeOrder_shouldSucceed_whenBalanceIsEnough() {
      // Mock BalanceChecker接口
      BalanceChecker mockChecker = mock(BalanceChecker.class);
      when(mockChecker.hasSufficientBalance("user123")).thenReturn(true);
      
      PlaceOrderService service = new PlaceOrderService(mockChecker);
      OrderResult result = service.placeOrder(new OrderRequest("user123", 100));
      
      assertTrue(result.isSuccess());
  }
  

  这里Mock的是「余额校验的契约」，而非PlaceOrder的内部实现。哪怕以后PlaceOrder改成用缓存服务，只要缓存服务也实现BalanceChecker接口，测试代码完全不用改——这正是TDD驱动设计的价值所在。

3. 为什么Mock依赖契约不违和？ #

作为PlaceOrder的使用者，你不需要知道它用什么方式获取余额，但你需要明确它依赖余额校验能力才能正常工作。Mock这个契约，只是为了在单元测试中隔离被测服务，确保PlaceOrder自身的逻辑（比如余额充足就允许下单，不足就拒绝）是正确的，而非测试依赖服务的正确性。

内容的提问来源于stack exchange，提问作者whowhenhow