仅封装.NET静态方法的文件IO包装类是否需要单元测试？

首先说你现有测试的问题 #

你现在用Mock<IFileIOWrapper>写的所有测试，测的是Moq框架生成的代理对象，和你自己写的FileIOWrapper实现类半毛钱关系都没有——你Setup什么Mock就返回什么，哪怕你FileIOWrapper里的代码全写错了，比如把ReadAllText转发给File.Delete，这些测试照样全过，完全没有验证价值。

为什么这种薄包装一定要写测试 #

不要信什么“只是转发调用没有业务逻辑就不用测”的说法，原因非常实际：

• 你写这个包装层的核心价值就是给上层业务屏蔽静态方法依赖、支持Mock，如果你的包装代码本身写错了——比如参数传反了、手滑调错了原生方法、返回值取错了属性（比如FileSize里不小心写成返回new FileInfo(path).CreationTime.Ticks），上层业务的所有Mock测试就算跑100%通过率，上线直接出生产事故，这种低级错误光靠代码评审很容易漏。
• 这种类的测试写起来极快，维护成本几乎为零，跑起来也是毫秒级，投入产出比高到离谱，完全没有理由跳过。
• 你不需要测.NET原生File类的逻辑——微软已经给System.IO做过全量测试了，你要测的只有一件事：你的包装代码有没有正确把调用转发给原生方法，入参有没有原封不动传对，返回值有没有原封不动透传。

测试用例设计方案 #

直接用真实文件系统测就行，不要Mock，所有操作放在系统临时目录下完成，测试结束自动清理，不会有环境污染问题，速度快到完全可以放进CI流水线：

• 不要硬编码固定路径（比如你之前写的C:\mellon是坏实践，跨平台、低权限环境直接跑挂），每个测试用例生成独立的GUID命名的临时文件夹，用例之间完全隔离
• 只测正向场景就够，不用测非法路径、权限不足、文件不存在抛异常这类场景——这些都是原生File类已经覆盖的逻辑，你没有加任何额外处理，测这些纯属重复劳动
• 每个公开方法对应1-2个正向用例即可：
  • Exists：验证存在的文件返回true，不存在的返回false
  • ReadAllText：提前写入已知内容的文件，验证读出来的内容完全匹配
  • WriteAllText：调用方法写入指定内容，直接用原生方法读文件验证内容正确
  • FileSize：生成已知字节长度的文件，验证返回的文件大小和预期一致

参考测试实现（MSTest） #

[TestClass]
public class FileIOWrapper_Implementation_Tests
{
    private string _testRootDir;
    private FileIOWrapper _wrapper;

    [TestInitialize]
    public void Setup()
    {
        // 每个测试用例分配独立临时目录，避免互相干扰
        _testRootDir = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString("N"));
        Directory.CreateDirectory(_testRootDir);
        _wrapper = new FileIOWrapper();
    }

    [TestCleanup]
    public void Cleanup()
    {
        // 测试结束清理临时文件，不留垃圾
        if (Directory.Exists(_testRootDir))
            Directory.Delete(_testRootDir, recursive: true);
    }

    [TestMethod, TestCategory("CI")]
    public void Exists_ExistingFile_ReturnsTrue()
    {
        var testFile = Path.Combine(_testRootDir, "test.txt");
        File.WriteAllText(testFile, "test");
        Assert.IsTrue(_wrapper.Exists(testFile));
    }

    [TestMethod, TestCategory("CI")]
    public void Exists_NonExistentFile_ReturnsFalse()
    {
        var testFile = Path.Combine(_testRootDir, "notexist.txt");
        Assert.IsFalse(_wrapper.Exists(testFile));
    }

    [TestMethod, TestCategory("CI")]
    public void ReadAllText_FileWithKnownContent_ReturnsMatchingContent()
    {
        var testFile = Path.Combine(_testRootDir, "readtest.txt");
        const string expectedContent = "mellon";
        File.WriteAllText(testFile, expectedContent);
        
        var actual = _wrapper.ReadAllText(testFile);
        
        Assert.AreEqual(expectedContent, actual);
    }

    [TestMethod, TestCategory("CI")]
    public void WriteAllText_ValidInput_WritesContentToDisk()
    {
        var testFile = Path.Combine(_testRootDir, "writetest.txt");
        const string expectedContent = "mellon";
        
        _wrapper.WriteAllText(testFile, expectedContent);
        
        Assert.AreEqual(expectedContent, File.ReadAllText(testFile));
    }

    [TestMethod, TestCategory("CI")]
    public void FileSize_FileWithKnownLength_ReturnsCorrectByteCount()
    {
        var testFile = Path.Combine(_testRootDir, "sizetest.txt");
        const long expectedSize = 3018;
        File.WriteAllBytes(testFile, new byte[expectedSize]);
        
        var actualSize = _wrapper.FileSize(testFile);
        
        Assert.AreEqual(expectedSize, actualSize);
    }
}

补充说明 #

• 这类测试虽然依赖真实文件系统，但依然属于单元测试范畴——你的测试边界就是FileIOWrapper本身，文件系统是所有运行环境都具备的基础依赖，单用例耗时不到1毫秒，完全不会拖慢CI速度。
• 你之前写的那堆基于Mock的测试可以直接删掉，Mock的正确用法是在测试依赖IFileIOWrapper的上层业务类时，用来模拟文件操作返回值，隔离业务逻辑和外部IO，拿Mock测接口实现本身属于逻辑错误。

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