企业应用单元测试：Mock交互验证与可观测结果测试困惑

你并没有遗漏核心要点，而是混淆了单元测试与集成测试的职责边界，同时对「可观测结果」的理解需要结合测试层级来调整。

1. 单元测试的核心：聚焦被测对象的逻辑，而非依赖的执行细节 #

单元测试的目标是验证被测对象（比如示例中的Customer）自身的逻辑正确性，而不是依赖组件（IStore）的执行结果。

你示例中的Verify(x => x.RemoveInventory(...))之所以被认为是测试实现细节，是因为它绑定了Customer与IStore交互的具体方法名——如果后续业务调整，IStore把RemoveInventory改名为DeductStock，哪怕Customer的业务逻辑完全正确，这个单元测试也会失败。

正确的单元测试应该聚焦Customer的可观测输出或状态变化：

• 如果Purchase方法除了返回bool，还会生成订单记录、更新用户的购买历史，那测试就验证这些结果；
• 如果当前Purchase只有返回值，可考虑重构代码，让它返回包含业务上下文的结果对象（比如PurchaseResult），测试只需验证该对象的属性是否符合预期。

改进后的单元测试示例：

public void Purchase_succeeds_when_enough_inventory(){
   var storeMock = new Mock<IStore>();
   storeMock.Setup(x => x.HasEnoughInventory(Product.Shampoo, 5)).Returns(true);
   
   var customer = new Customer();
   PurchaseResult result = customer.Purchase(storeMock.Object, Product.Shampoo, 5);
   
   Assert.True(result.IsSuccess);
   Assert.Equal(Product.Shampoo, result.PurchasedProduct);
   Assert.Equal(5, result.Quantity);
}

2. 库存实际扣除的验证：交给集成测试 #

当你需要确认「库存是否真的被扣除」时，这已经超出了单元测试的范围——单元测试不负责验证依赖组件的实际执行效果，这是集成测试的职责。

集成测试中，你不需要Mock数据库或DAO，而是使用真实的测试数据库（比如内存数据库、独立测试库），执行完整的业务流程后，直接查询数据库验证库存变化：

public void Purchase_deducts_inventory_in_database(){
   // 准备测试数据：初始化Shampoo库存为10
   var realStore = new DatabaseStore(TestDbConnection);
   realStore.AddInventory(Product.Shampoo, 10);
   
   var customer = new Customer();
   bool success = customer.Purchase(realStore, Product.Shampoo, 5);
   
   Assert.True(success);
   // 直接查询数据库验证剩余库存
   int remainingStock = realStore.GetInventory(Product.Shampoo);
   Assert.Equal(5, remainingStock);
}

3. 补充：契约测试的可选方案 #

如果你的系统依赖大量外部服务或接口，还可以引入契约测试，验证Customer与IStore之间的交互契约是否符合约定——但这通常是在单元测试和集成测试之外的补充，核心还是区分不同测试层级的职责。

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