你提到的包装类方案确实可行，但其实有更简洁的方式——不用额外编写包装类，直接针对IFoo接口创建Mock，将需要保留真实逻辑的方法委托给Bar的实例即可，具体实现如下：

实现步骤 #

1. 先创建一个真实的Bar实例，用于提供你想保留的方法实现；
2. 对IFoo接口创建Mock对象；
3. 通过Setup配置：需要Mock的方法自定义返回/行为，需要真实执行的方法直接指向真实Bar实例的对应方法。

代码示例 #

// 1. 初始化真实的Bar实例
var realBarInstance = new Bar();

// 2. 创建IFoo的Mock对象
var mockFoo = new Mock<IFoo>();

// 3. 配置需要Mock的方法（这里自定义DoAnotherThing的返回结果）
mockFoo.Setup(f => f.DoAnotherThing()).Returns("Mocked version of DoAnotherThing");

// 配置需要执行真实逻辑的方法，直接委托给realBarInstance的实现
mockFoo.Setup(f => f.DoSomething()).Returns(() => realBarInstance.DoSomething());

// 使用Mock后的IFoo实例
IFoo testFoo = mockFoo.Object;

// 调用测试
Console.WriteLine(testFoo.DoSomething()); // 输出真实Bar的结果："DoSomething"
Console.WriteLine(testFoo.DoAnotherThing()); // 输出Mock的结果："Mocked version of DoAnotherThing"

为什么这个方式更高效？ #

• 无需额外编写包装类（比如你提到的MockableBar），减少冗余代码；
• 完全利用Moq原生API实现逻辑拆分，配置灵活：想换哪个方法Mock/保留真实实现，直接调整Setup即可；
• 符合依赖倒置原则：业务代码原本依赖IFoo接口，Mock接口的方式不会改变原有的依赖关系，更利于后续维护。

注意点 #

如果你的场景必须直接MockBar类（而非接口），由于Bar是sealed的，Moq默认不支持Mock密封类。这种情况下要么调整设计（优先依赖接口是更推荐的实践），要么使用支持Mock密封类的工具（比如TypeMock）。

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