使用委托作为“工厂方法”用于c#中的单元测试

本文关键字：用于 工厂方法 单元测试 方法 工厂 | 更新日期: 2023-09-27 18:16:39

问题

让我们"画"一幅情景图:

    我有SUT。(有P是件好事)
  • 我可以在SUT上注入一些依赖项。
  • 在一个方法中，我做一个:new OtherClass(parametersobtainedfromdependances)。
  • 我想在SUT中对该方法进行单元测试，而不处理创建模拟对象的复杂性，使OtherClass能够正确工作。这意味着测试OtherClass

我的解决方案是使用委托的工厂方法:

public Func<OtherClass,Param1Type> GetOtherClass = 
       (param1) => new OtherClass(param1);

坏处:它是公开的。您可以将其视为可选的依赖项，如果需要可以覆盖它。但无论如何，公共气味。

优点:我不需要创建一个MyTestSUT来覆盖这个方法，甚至不需要在SUT上使用一个mock来覆盖那个方法。

有更好的解决方案吗?这是正确的吗?

使用委托作为“工厂方法”用于c#中的单元测试

为什么把它设为公共字段?听起来它基本上是一个依赖，像任何其他:你想要的东西，将提供给你一个OtherClass，当你给它一些其他的值。为什么不把它当作构造函数参数，就像其他依赖项一样(或者不管你在做依赖注入的其余部分)?

如果你愿意，你总是可以提供一个构造函数重载而不带这个参数，它委托给较长的参数。这就是我通常提供"默认"依赖实现的方式。

换一种方式:这在逻辑上与(说)IAuthenticator接口有什么不同，当提供用户名和密码时，将返回UserProfile ?你碰巧使用委托作为避免声明接口的捷径，但在我看来，这只是一个细节。您可能会发现，随着时间的推移，您实际上希望在"提供"部分添加更多的智能-例如缓存。

听起来您想使用类似于AutoFixture的东西，并启用AutoMoq自定义。这将使您能够模拟SUT中的所有或部分公共字段，如果您愿意，还可以模拟其他构造函数参数。

相关文章：