dependency-injection - 运行注入(inject)代码的集成测试库的正确方法是什么？

Question

我有两个软件组件:我的应用程序和一个由应用程序使用的库(由我的公司拥有，但另一个团队拥有)。该库是某些服务的客户端库并执行 HTTP 请求。该库还将 HTTP 响应映射到应用程序的内部表示。这是通过应用程序将映射类注入(inject)到库中来完成的。

我已经对映射类和应用程序进行了单元测试，而客户端库调用总是被模拟的。

现在我正在考虑对库进行集成测试，但我不确定最好的方法是什么:

模拟库调用，只检查它是否使用正确的参数调用

Pro:如果库的内部结构发生变化(非破坏性变化)，我不必调整我的测试。

缺点:映射类没有经过集成测试。我不能确定库是否正确配置，或者映射器从库中获取的参数是否符合我的预期。

仅模拟库 完成的 HTTP 调用

亲:映射类和库的配置(如果我配置正确的话)已经过测试。

缺点:我需要弄清楚库的内部结构并检查每个测试用例的 HTTP 调用的样子。此外，如果库升级到新版本的服务，我还需要调整所有 HTTP 模拟，实际上不应该关心库内部的工作方式。

在测试期间将库中的 HTTP 调用替换为内存中的假 (=dummy) 实现

优点:一切都经过测试 + 测试对库更改具有弹性。

缺点:这是实现和维护虚假实现的努力。根据服务的不同，这可能意味着在图书馆中重建服务的功能。谁应该为虚假策略负责(实现+维护)？我的团队还是拥有图书馆的团队？

我赞成最后一点，但鉴于我们图书馆的内部结构很少改变，我不确定一个虚假的策略是否值得努力。

您对此有何看法？你能想出另一种解决方案吗？

Answer 1

我将在库中创建允许您模拟 HTTP 响应的助手。因此，您会看到在库中运行的代码，并且您可以使用验证 JSON 格式的库来确保 http 请求/响应是您所期望的。

从这个意义上说，您正在检查 i) 库实际上与您的系统一起使用； ii) 处理正确的 HTTP 响应；因此，您的助手可能很简单，因此开发人员只需要提供 http 响应的内容