有人负责创建一组“核心”库,创建了一组静态类,提供各种实用程序,包括日志记录、审计和常用数据库访问方法。
我个人认为这很糟糕,因为我们现在有一组难以测试的核心库,因为我无法模拟/存根这些类或对它们的构造函数进行任何注入。
我想我可以使用 TypeMock 将它们存根,但我宁愿免费做。
你怎么看?
编辑
如果您认为它们不难测试,您能否举例说明如何测试它们。这些静态类实例化其他类型来完成它们的功能。
有人负责创建一组“核心”库,创建了一组静态类,提供各种实用程序,包括日志记录、审计和常用数据库访问方法。
我个人认为这很糟糕,因为我们现在有一组难以测试的核心库,因为我无法模拟/存根这些类或对它们的构造函数进行任何注入。
我想我可以使用 TypeMock 将它们存根,但我宁愿免费做。
你怎么看?
编辑
如果您认为它们不难测试,您能否举例说明如何测试它们。这些静态类实例化其他类型来完成它们的功能。
静态类(方法)不一定要避免,只要它们没有隐藏的依赖关系。当然,您可以将依赖项传递给静态方法 - 它不应该存储在内部并修改以后调用的行为。
在这种情况下测试它们也应该没有问题。
但我也对你提到的案例有不好的预感。我知道其中一些静态“包装器”实用程序类 - 在大多数情况下它们真的很臭:)
编辑:
也许我应该澄清一下。我只会将静态类/方法用于非常小的杰出任务。当静态类开始初始化依赖项时,当然应该避免它们。如果你不能测试这些静态类,它们就已经有很大的工作要做了。
正如您提到的,在这个问题的第一个答案中是反对静态类的论点。
修改这些静态类以利用依赖注入有多难?如果您将 DI 设为可选(如果可能),则基本上可以通过正确执行 DI 来使用静态类进行模拟,同时不更改任何“正常”行为。
以下摘自《对象技术杂志》:将职责与静态方法分离以实现细粒度可配置性
静态方法通过硬连线实例创建对测试的开发造成障碍。对开源 Smalltalk 代码中的 120 个静态方法的研究表明,在 120 个静态方法中,只有 6 个不能同样很好地实现为实例方法,但事实并非如此,因此给调用者带来了对这些静态方法的隐式依赖的负担