工具类该选依赖注入还是静态类？单元测试困境求解

1. 接口抽象+构造注入（最推荐的测试友好方案） #

你之前觉得在ExportOutput方法里注入违和，核心原因是应该用构造注入而非方法注入。把工具类的依赖放到Component类的构造函数中，既符合依赖注入的“依赖倒置”原则，也让代码结构更清晰。

举个具体实现：

// 定义抽象接口
public interface IFileCopier
{
    void CopyFile(string sourcePath, string destinationPath);
}

// 基于System.IO.Abstraction的实现类
public class FileCopier : IFileCopier
{
    private readonly IFileSystem _fileSystem;

    public FileCopier(IFileSystem fileSystem)
    {
        _fileSystem = fileSystem;
    }

    public void CopyFile(string sourcePath, string destinationPath)
    {
        _fileSystem.File.Copy(sourcePath, destinationPath, overwrite: true);
    }
}

// 业务类Component——用构造注入依赖
public class Component
{
    private readonly IFileCopier _fileCopier;

    // 构造函数注入，而非方法传参
    public Component(IFileCopier fileCopier)
    {
        _fileCopier = fileCopier;
    }

    public void ExportOutput(string source, string target)
    {
        // 直接使用注入的实例，完全无违和感
        _fileCopier.CopyFile(source, target);
        // 其他业务逻辑...
    }
}

测试时直接Mock IFileCopier即可，完全隔离System.IO的真实调用。

2. 静态类的可配置依赖（兼容现有代码的过渡方案） #

如果不想大规模重构现有静态工具类的调用方式，可以给静态类添加一个可替换的依赖入口，兼顾便利性和可测试性：

public static class FileCopier
{
    // 暴露可配置的文件系统依赖，默认用真实实现
    public static IFileSystem FileSystem { get; set; } = new FileSystem();

    public static void CopyFile(string sourcePath, string destinationPath)
    {
        FileSystem.File.Copy(sourcePath, destinationPath, overwrite: true);
    }
}

测试时只需在测试初始化阶段替换依赖：

// 测试用Mock替换
var mockFileSystem = new Mock<IFileSystem>();
FileCopier.FileSystem = mockFileSystem.Object;

// 执行测试逻辑
FileCopier.CopyFile("src", "dest");

// 验证调用
mockFileSystem.Verify(fs => fs.File.Copy("src", "dest", true), Times.Once);

这种方案不用改原有业务代码的调用方式，适合快速修复测试问题。

3. 扩展方法+接口抽象（适合通用场景的工具函数） #

如果工具函数是对某个基础能力的扩展（比如文件操作、字符串处理），可以基于接口写扩展方法，既保留静态调用的简洁性，又能支持测试：

// 基于IFileSystem的扩展方法
public static class FileSystemExtensions
{
    public static void CopyWithValidation(this IFileSystem fs, string source, string dest)
    {
        if (!fs.File.Exists(source))
            throw new FileNotFoundException("源文件不存在", source);
        
        fs.File.Copy(source, dest, overwrite: true);
    }
}

业务类中注入IFileSystem后，直接调用扩展方法：

public class Component
{
    private readonly IFileSystem _fileSystem;

    public Component(IFileSystem fileSystem)
    {
        _fileSystem = fileSystem;
    }

    public void ExportOutput(string source, string target)
    {
        _fileSystem.CopyWithValidation(source, target);
        // 其他逻辑...
    }
}

扩展方法的逻辑会随着IFileSystem的Mock一起被测试，灵活性很高。

4. 局部/私有方法抽离（仅适用于单一类的专属工具） #

如果某个小型工具函数只服务于单个业务类，没必要单独做静态类或接口，直接抽成类的私有/内部方法即可：

public class Component
{
    public void ExportOutput(string source, string target)
    {
        ValidateFileExists(source);
        CopyFile(source, target);
        // 其他逻辑...
    }

    // 私有工具方法，仅服务于当前类
    private void CopyFile(string source, string target)
    {
        File.Copy(source, target, overwrite: true);
    }

    private void ValidateFileExists(string path)
    {
        if (!File.Exists(path))
            throw new FileNotFoundException(path);
    }
}

测试时通过调用ExportOutput来覆盖私有方法的逻辑，如果需要单独测试私有方法，可以用InternalsVisibleTo属性把私有方法改为内部方法，让测试项目访问。

你提到的“将方法移至可依赖注入的位置”是完全正确的做法——构造注入是DI的标准实践，比方法注入更符合“依赖前置声明”的原则，避免了方法参数冗余的问题。

内容的提问来源于stack exchange，提问作者Philippe Balleydier