.NET Moq框架：Mock接口与Mock类的选型及差异咨询

作为Moq新手，你纠结的这个问题其实是单元测试中「依赖抽象还是依赖实现」的典型场景，结合你的示例代码，我来帮你拆解两种方式的差异和各自的优缺点：

当前场景下两种Mock方式的差异 #

先看你的代码：Client依赖的是Ifoo接口，不管你用var mock = new Mock<Ifoo>();还是var mock = new Mock<Foo>();，最终都可以把mock.Object作为Ifoo实例传给Client构造函数，在直接功能上是等价的——因为你只需要MockBar()方法，而Foo的Bar()是virtual的，两种方式都能成功拦截并自定义它的返回值。

但两者还是有细微区别：

• Mock<Ifoo>创建的是一个完全基于接口定义的Mock对象，它和具体的Foo类没有任何关联，只实现了Ifoo中定义的方法。
• Mock<Foo>创建的是Foo类的动态代理子类，它继承了Foo的所有成员：除了能MockBar()这个virtual方法，如果你调用它的非virtual成员（假设Foo有），会直接执行原Foo类的逻辑，而Mock<Ifoo>根本不会有这些额外成员。

Mock接口 vs Mock具体类的优缺点 #

Mock接口的优势 #

• 贴合依赖倒置原则：你的Client依赖的是抽象接口，测试时Mock抽象，能更纯粹地验证Client和接口的交互逻辑，完全和具体实现解耦。
• 无Mock限制：接口的所有方法默认都可以被Mock，不需要担心方法是否标记为virtual，避免了因为漏加virtual导致Mock失败的坑。
• 轻量干净：基于接口的Mock只包含接口定义的成员，没有具体类的冗余逻辑、构造函数副作用，测试过程更可控，不会出现意外的依赖影响。

Mock接口的不足 #

• 唯一的小问题是如果后续修改了接口定义但没同步更新测试，可能会出现测试与实际代码不一致的情况，但这本质是接口维护的问题，而非Mock方式的缺陷。

Mock具体类的优势 #

• 当被测试类直接依赖具体类（而非接口），且暂时无法重构为依赖抽象时，Mock具体类是可行的替代方案。
• 如果具体类中有一些无需Mock的辅助方法（非virtual），Mock具体类可以直接复用这些方法的实现，省去额外Mock的工作量。

Mock具体类的劣势 #

• 只能Mock virtual/abstract方法：这是最致命的限制，如果具体类中的方法不是virtual的，Moq无法拦截它，会直接执行原方法，很可能导致测试结果不符合预期。
• 潜在的构造副作用：Mock具体类时，Moq需要创建该类的子类实例，这会触发原类的构造函数（除非显式设置CallBase = false），如果构造函数有复杂依赖或副作用，会给测试带来不必要的麻烦。
• 绑定具体实现：测试依赖具体类，会让测试和实现细节绑定更紧，后续修改具体类可能导致测试失败，降低了测试的稳定性和可维护性。

给你的具体建议 #

你自己的判断完全正确——Mock接口是这个场景下的更优方案。因为你的Client依赖的是Ifoo抽象，Mock接口完全能满足测试需求，还能避免Mock具体类带来的各种限制和潜在问题，让你的测试更聚焦于业务逻辑的交互，而非具体实现细节。

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