无法测试Braintree API：我应该改变源代码还是单独包装每个类？

Question

我正在与Braintree API for .NET合作来处理付款。他们的业务在处理付款方面做得很好，API包装器可以直接使用。但是，提供的API封装器在经过更仔细的调查或更加剧烈的使用后会快速失败;例如，它包含手卷enum s。我的问题是单元测试使用这个包装器的代码。

为了做到这一点，我基本上需要模拟我自己的'假'Braintree网关，它会有一些已知的值，请求时会产生错误等。我的攻击计划是覆盖Braintree API封装器并将请求重新路由到本地内存中端点。然后我可以在运行时使用依赖注入来连接正确的网关/包装器。尽管在API封装器中犯下了针对软件工程的罪行，但我需要覆盖的每种方法都被奇迹般地标记为virtual。然而，这是一个急刹车：API包装中的几乎构造函数被标记为internal。因此，我既不能继承这些类，也不能随意创建它们来存储测试。

另一方面：我建议使用internal，以及合理使用它们的原因。然而，我已经看过这个源代码，并且每个构造函数都只执行简单的属性分配。因此，我很自信地宣称应遵循不同的编码习惯。

所以，我基本上只剩下三个选择：

1. 重新编写我自己的API的包装。这显然是可行的，并且具有产生设计良好的基础设施的优点。但是，这些缺点太多，不能简单列举。

2. 从API下拉源代码并将其包含在我的解决方案中。我可以将所有的internal构造函数改为任何我需要的工具。缺点是我不得不在每个后续的API封装版本上重新更新所有这些更改。

3. 为我需要在整个API包装器中使用的每个对象编写包装类。这具有不改变提供的源代码的优点;但是缺点很大：基本上重写三次包装中的每个类（一个接口，一个Braintree API包装适配器和一个可测试版本）。

不幸的是，所有这些吸引。我觉得选项2可能是最差的选项，但它让我感觉很脏。有没有人已经解决了这个问题/写了一个更好，更可测试的包装？如果没有，我是否错过了一个可能的行动方案？如果不是，那三个选项中的哪一个似乎最不令人讨厌？

Answer 1

也许this stackoverflow entry可以帮助

此外，A random blog entry on the subject

Answer 2

既然你没有测试他们的API，我会用Facade模式。你不需要包装他们提供的所有东西，只是封装你正在使用的功能。这也给了你一个优势：如果你决定在将来抛弃这个API，你只需要重新实现你的包装。