关于测试代码中Stub、Mock判定及断言合理性的技术问询

咱们逐个拆解你的三个问题，先明确一下Stub和Mock的核心区别：Stub主要用来给被测系统提供预设的依赖数据/返回值，让测试能顺利进行；Mock则更关注验证被测系统与依赖之间的交互行为（比如方法是否被调用、调用次数等）。搞清楚这个核心差异，问题就好解决了。

技术问询1：BuildExpectedTable是否属于Stub？针对它断言是否不当？ #

首先，BuildExpectedTable不是Stub。Stub的作用是给被测对象的依赖提供数据——比如如果你的Service依赖另一个外部组件，你用Stub模拟那个组件的返回值，那才是Stub。而这里的BuildExpectedTable只是一个辅助方法，用来生成预期的结果数据集，目的是和service.GetMonths()返回的实际结果做对比。

另外，你的代码里并没有“针对BuildExpectedTable进行断言”——你是在用它生成的t2和实际结果t1做断言，这是完全合理的测试做法。我们测试的核心是验证Service.GetMonths()的输出是否符合预期，BuildExpectedTable只是帮我们构造了一个基准参照，没有任何问题。

技术问询2：这段Moq代码是Mock，是否可能被视为Stub？ #

当然可以！Mock框架（比如Moq）的灵活性很强，它可以同时扮演Stub和Mock的角色，关键看你怎么使用它：

• 当你用它验证交互行为（比如调用Verify方法检查某个方法是否被调用）时，它是Mock；
• 当你用它提供预设的返回值/属性值，只是为了让被测代码能正常运行时，它就是Stub。

你的这段代码：

var mockCalculator = new Moq.Mock<ICalculator>();
mockChangeCalculator.SetupProperty(client => client.Number1, 400).SetupProperty(client => client.Number2, 200);

只是给ICalculator的属性设置了预设值，如果后续测试里你没有验证这些属性是否被访问/修改，只是让被测代码使用这些值，那它此时的角色就是Stub。本质上，这个Moq对象在这里就是一个Stub，Mock工具只是实现Stub的一种方式而已。

技术问询3：此处的expected是否属于Stub？ #

expected数组不是Stub。它和第一个问题里的BuildExpectedTable类似，只是用来验证ProcessInput输出结果的预期基准数据。Stub是给被测系统的依赖提供数据——比如如果ProcessInput需要调用某个外部API获取输入值，你用Stub模拟那个API的返回，那才是Stub。而这里的expected只是用来断言结果是否正确的参照，和Stub的功能完全不沾边。

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