0

问题

让我们“画”出一幅情景图：

  • 我有一个 SUT。（有一件好事：P）
  • 我可以在我的 SUT 上注入一些依赖项。
  • 在我做的一个方法中：new OtherClass(ParametersObtainedFromDependancies)。
  • 我想在我的 SUT 中对该方法进行单元测试，而无需处理创建对 OtherClass 正常工作有意义的模拟对象的复杂性。这意味着要测试 OtherClass。

我对此的解决方案是使用委托的工厂方法：

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

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

好处：我不需要创建将覆盖此方法的 MyTestSUT，甚至不需要在 SUT 上使用模拟来覆盖该方法。

问题

有没有更好的解决方案？它是否正确？

4

2 回答 2

2

你为什么把它变成公共领域？听起来它基本上像任何其他依赖项一样：你想要一些东西，OtherClass当你给它一些其他值时，它会为你提供一个。为什么不像其他依赖项一样将其作为构造函数参数（或者您正在执行其余的依赖项注入）？

如果您愿意，您始终可以提供没有此参数的构造函数重载，该参数委托给更长的参数。这就是我通常提供“默认”依赖项实现的方式。

换句话说：这在逻辑上与（比如说）一个IAuthenticator接口有什么不同，当提供用户名和密码时，它会返回一个UserProfile? 您碰巧使用委托作为避免声明接口的捷径，但这只是 IMO 的一个细节。您可能会发现，随着时间的推移，您实际上希望在“提供”部分添加更多智能——例如缓存。

于 2011-12-03T12:41:39.747 回答
0

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

于 2011-12-03T12:45:05.463 回答