.net - 单例以促进遗留代码库中的单元测试。好主意与否？

Question

伙计们，
我有一个庞大的遗留 .Net 代码库，我正在尝试向团队介绍单元测试。他们是好人，但这对他们来说是全新的(老实说，这对我来说也是相当新的)。

问题之一是代码库大量使用 System.IO 中的静态类，有大量的内部静态类库，并且类没有写入接口(interface)(除非有实际的设计理由这样做)。

我正在使用 NUnit 和 FakeItEasy 开发一个简单易用的策略。

为了解决静态类依赖关系，我编写了一个为现有静态类生成包装类和接口(interface)的工具。例如在配置文件中，我说我想要 System.IO Directory & File 的包装器，该工具会生成一个程序集，其中的代码类似于 . . .

public interface IFile
{
    // All Method signatures taken from System.IO.File
}

internal class File
    : IFile
{
    // All Methods delegate to System.IO.File
}

public interface IIO
{
    IFile File {get;}
    IDirectory Directory {get;}
}

internal class IO
    : IIO
{
    public IFile File {get; private set;}
    public IDirectory Directory {get; private set;}
    public IO()
    {
        File = new File();
        Directory = new Directory();
    }
}


public static class IO
{
    public IIO Instance {get; set;}
    static IO()
    {
        Instance = new IO();
    }
}

这个想法是，在现有代码库中可以通过查找/替换和添加新项目引用来简单地更新，并且在单元测试中您可以将 Mock 对象分配给 IO.Instance .

一方面，我对这种方法非常满意，它提供了一种干净、快速的方式来摆脱直接使用静态类，此外还为我们提供了一种模拟这些静态类并让我们测试依赖于它们的代码的方法。

另一方面，我觉得我和魔鬼做了一笔交易，我已经用对 的依赖替换了对隐式单例的依赖。显式 单例。

在不久的将来的某个时候，这一切对我来说会变得非常糟糕，还是你认为这是一种可行的方法？

Answer 1

我会像你对遗留应用程序那样做。无需重构较大的部分，您无能为力。它仍然很灵活，因为您可以通过静态类更改实现。

一种想法可能是仅使 Instance 方法静态并在您的 IOC 中注册 IO 类(作为单例)。然后让 IOC 找到正确的实现(由静态 Instance 方法返回)。

IoC 容器的精彩介绍:http://joelabrahamsson.com/entry/inversion-of-control-introduction-with-examples-in-dotnet