【问题标题】:Adapting Interfaces for Moq unittest为 Moq 单元测试调整接口
【发布时间】:2019-01-08 20:05:22
【问题描述】:

我在一个项目中遇到了问题,其中一些第三方类存在问题。问题是我们无法从第三方实例化类,因为我们只能获得元数据表示,但我们可以通过适配器模式来解决这个问题。问题是我们需要单元测试的类实现了第三方接口:

public class OurClass: ThirdPartyInterface
{

}

这些接口返回第三方类(我们可以通过适配器模式包装的那些),但它们会作为原始类返回。所以我们需要以某种方式创建某种适配器接口系统。

目前我们最好的想法是创建一个实现ThirdpartyInterface的类(FacadeThirdParty),然后将来自接口(TPClass)的第三方类包装成一个适配器类(TPClassAdapter),然后通过我们自己的接口发送“OurClass”实现的(IFacadeThirdPartyInterface):

这样我们可以Moq我们的IFacadeThirdPartyInterface和适配器类接口,而不会被第三方打扰。这个想法有什么好处吗?我觉得可能有更好的方法来做到这一点。

更新:新提议的解决方案

所以经过一些想法和 cmets 中所说的话,我认为我有一个可行的新解决方案:

我遇到的问题是第三方系统使用的回调函数,我可能没有很好地解释。所以,我在这里所做的是我们有我需要进行单元测试的“OurClass”。它现在将与 Facade 层对话并通过 IFacadeCallback 接口获取回调。所有第三方接口都将在外观类中实现。当这些接口之一执行对外观的调用时,它将通过 IFacadeCallback 外观重定向它。如果调用有第三方类,它会将它们包装在适配器类中并返回该类的接口(ITPClass)。理论上,这应该隔离“OurClass”,以便我可以使用 Moq 来测试它的功能。

【问题讨论】:

  • 完全抽象出第 3 方的依赖关系。如您所见,与您无法控制的问题紧密耦合会使事情变得困难。
  • @Nkosi 那么像我更新帖子的新解决方案一样吗?你是这么想的吗?

标签: c# unit-testing mocking


【解决方案1】:

我要做的不是使用适配器模式,而是将第三方的依赖注入到您要测试的类中,例如

public class OurClass
{
    public OurClass(IThirdPartyInterface thirdParty)
    {
        _thirdParty = thirdParty;
    }
    private readonly IThirdPartyInterface _thirdParty;
}

接口IThirdPartyInterface 将是一个简单的接口,其中包含您在ThirdPartyInterface 类的代码中需要的方法/属性。

这样做你可以轻松地模拟这个类的依赖关系,而且这也建立在依赖倒置原则之上。

【讨论】:

  • 我想我知道你要去哪里了,但这里的问题是我可以模拟 IThirdPartyInterface,但我不能模拟或实例化接口需要或返回的任何第三方类。
  • 在这种情况下,我会说您不是单元测试,如果您想测试第三方的实现,那么您将执行集成测试。您应该做的是模拟接口方法和返回,这样您就可以对代码进行单元测试,而不必担心第三方的实现
  • 哦,我根本不想测试第三方。它们是通信实体。我想我可以使用它们在其中输入一些数据并通过 Mocked 第三方接口将它们发送到我的班级,并确保“OurClass”中的代码正确处理它。但是,我无法实例化任何第三方类。所以,我需要为第三方类制作适配器,并使用第三方接口制作一些系统,这样它们就不会返回第三方类,而是返回我的适配器类。这意味着我需要在第三方接口和“OurClass”之间有一个层
猜你喜欢
  • 2012-11-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-09-22
  • 1970-01-01
  • 1970-01-01
  • 2018-01-26
  • 1970-01-01
相关资源
最近更新 更多