应该避免使用静态类,因为它会使依赖注入困难吗?

时间:2009-05-20 15:30:25

标签: c# dependency-injection mocking testability

负责创建“Core”库的人创建了一组静态类,提供了各种实用程序,包括日志记录,审计和常见的数据库访问方法。

我个人认为这很糟糕,因为我们现在有一组很难测试的Core库,因为我不能模拟/存根这些类或者对它们的构造函数进行任何注入。

我想我可以使用TypeMock来解决这些问题,但我宁愿免费使用它。

您怎么看?

修改

如果你不认为他们很难测试,你可以给出一个如何测试它们的例子。这些静态类实例化其他类型来完成它们的功能。

3 个答案:

答案 0 :(得分:8)

静态类(方法)不一定要避免,只要它们没有隐藏的依赖关系。当然,您可以将依赖项传递给静态方法 - 它不应该存储在内部并修改以后调用的行为 在这种情况下测试它们应该没有问题。

但我对你提到的案例也有不好的看法。我知道其中一些静态的“包装器”实用程序类 - 在大多数情况下它们确实很臭:)

修改:
也许我应该澄清一下。我会将静态类/方法仅用于非常小的区分任务。当静态类开始初始化依赖项时,它们当然应该避免。如果你无法测试这些静态类,那么他们已经有了太大的工作要做。

first answer of this question中是你提到的反对静态类的参数。

答案 1 :(得分:1)

以下来自Journal of Object Technology: Decoupling responsibilities from static methods for fine-grained configurability

  

静态方法通过硬连线实例创建对测试的开发造成障碍。对开源Smalltalk代码中的120种静态方法的研究表明,在120种静态方法中,只有6种方法不能像实例方法那样实现,但却没有,因此给它们的调用者增加了对这些静态方法的隐式依赖性< / p>

答案 2 :(得分:1)

修改这些静态类以使用依赖注入有多难?如果你将DI作为可选项(如果可能的话),你实际上可以通过正确地执行DI来使用静态类进行模拟,同时不改变任何“正常”行为。