单元测试代码,它调用静态方法

Question

我已经阅读了大多数与SO相关的问题(这里,这里和那里).最后一个问题提出了四种替代方法来生成调用静态方法单元可测试的代码.我想问一下我的具体情况:我们有一个"业务逻辑层"或"规则"项目,它包含45个静态类(没有状态,只有静态方法).而且,它们不易自行测试:大多数都访问数据库和文件系统.无论如何,它并没有那么糟糕:要访问数据库,他们使用某些Mapper类的唯一实例(所有Mappers都是Singletons).每当我尝试对某些东西进行单元测试时,我都会碰到这堵墙.最大的问题是这是非常非常重要的代码,应该非常仔细地计划对其进行更改.我的问题:我应该如何使这个单元更加可测试？我应该编写45个接口并使用依赖注入吗？即便如此,我如何存根/模拟Mappers？

PS:我一直在阅读Michael Feathers的"使用传统代码",所以欢迎直接引用(其他书籍也是:)

编辑:由于有些人说解决方案可能依赖于平台,我正在研究.NET(C#和一些VB.NET)

Answer 1

目前的情况可能是没有人敢在代码中改变任何东西,因为它可能以意想不到的方式破坏.确保每个人都明白你正在改善这种情况:你的更改可能会破坏代码,但与以前不同的是,这些破坏将被发现,一旦找到它们,它们将永远被修复.

也就是说,下一步取决于您的经验以及您对团队的信任.如果你想安全玩,请使用这样的代码(Java语法):

Mapper {
    public static Mapper INSTANCE = new Mapper(); // NEW code

    protected void doImpl() { // NEW CODE
        ... code copied from impl()... // OLD code, NEW PLACE
    }

    public static void impl() { // OLD code
        INSTANCE.doImpl(); // NEW code
    }

    // OLD code ...
}

这是一个非常简单的更改,允许您覆盖INSTANCE测试.对于生产代码,您不做任何事情,默认情况下,代码的行为与之前完全相同.

这样,您可以一次替换一个方法.您可以随时停止关注此路径 - 每次更改只需几分钟即可进行重构:代码完全按照以前的方式执行.由于每次更改都很小并且无法破坏任何内容,因此您可以替换一种方法,编写之前无法写入的所有单元测试,冲洗,重复.最后,如果您不想/需要重新修改所有静态方法,这种方法可以为您提供所需的全部余地.

在第二步中,您可以介绍DI或任何其他让您开心的技术.这种方法的优点是:当您进行复杂的更改时,您将拥有可以保护您的单元测试.

如果你从DI开始,你必须在各种地方改变很多代码 - 没有适当的单元测试可以保护你.