让第三方库实现接口的策略？答案

【问题标题】：Strategy to make a third-party library implement interfaces?让第三方库实现接口的策略？
【发布时间】：2013-09-30 10:43:09
【问题描述】：

我想为我的一些课程编写单元测试。我的一些类依赖于使用文件系统并且没有接口可模拟的第三方库。

我会模拟该类以避免它对文件系统的依赖，因为我的代码实际上只关心该代码的结果。

在不修改初始库的情况下模拟库的具体类的最佳策略是什么？

我想我可能会创建一个实现接口并包含初始库对象的包装器对象。但是，在我开始这条路之前，我想确保没有更好的方法。

或者，在这种情况下，像 TypeMock 这样的工具会比 Moq 更适合吗？

【问题讨论】：

不确定我是否完全理解 - 如果你想测试库是否正常工作，你为什么要模拟它？
抱歉，措辞不好——写得太快了。我将编辑：现在在移动设备上。本质上，我的意思是我想在我的代码测试中使用该库，但它使用文件系统。我想模拟它以使我的测试更快/更健壮。
好的，明白了。所以库依赖于文件系统，你想用“模拟”文件系统替换它。一个很好的问题。
谢谢！我希望主题是有价值的，即使最初的措辞不是。 :)
您知道该库是否使访问文件系统的方法可见（即public 或protected）和virtual？或者它是否与整个地方的文件系统混为一谈。

【解决方案1】：

背景：

除非它是像 .NET 框架这样的稳定库/框架，否则我更喜欢将我的代码与它解耦。也就是说，我喜欢让库依赖于我的系统，而不是相反。

编辑，重新调整：您可能会考虑使用“稳定”的库。但是，由于它与“外部”系统（文件系统）交互，我可能仍想将我的系统与它分离。

为此，我为库创建了一个适配器/包装器。该接口具有我的系统希望库具有的方法，而不是库碰巧提供的方法。该接口使用我的系统拥有的类型，而不是库中的任何类型。适配器会进行必要的转换。

无论我是否想模拟/存根/伪造库，我都会这样做，因为它提供了良好的关注点分离，还可以保护我的系统免受库中的更改。

回答您的问题：

一旦有适配器/包装器，就很容易在您的测试中伪造它。另外，由于适配器使用您系统的语言，因此编写易于阅读和理解的测试会更容易。

您是使用模拟框架还是为适配器编写自己的伪造品是一个品味问题。

【讨论】：

如果你走这条路，你仍然应该以某种方式测试你的包装器。包装器的单元测试可能过于简单，具体取决于您可以使其变得多么简单，但至少在集成测试中包含您的实际实现（不是模拟）。