Go 文件系统代码怎么用内存文件做单元测试

Go 文件系统代码如果直接调用 os.ReadFile，单元测试就会被真实目录、临时文件和机器环境牵着走。更稳妥的做法是让业务函数接收 fs.FS，测试时用标准库 testing/fstest 的 MapFS 在内存里准备文件。这样既不需要落盘，也能明确覆盖“文件存在、内容错误、文件缺失”这些分支。

先让文件读取函数依赖 fs.FS

要替换磁盘，第一步不是寻找 mock 库，而是把函数参数从具体路径改成 fs.FS。下面的例子读取固定的 config/app.json，解析后只返回业务真正关心的字段。

package config

import (
    "encoding/json"
    "fmt"
    "io/fs"
)

type App struct {
    Name string `json:"name"`
    Port int    `json:"port"`
}

func LoadApp(fsys fs.FS) (App, error) {
    // 业务只依赖 fs.FS，因此 os.DirFS、MapFS 都可以传入。
    data, err := fs.ReadFile(fsys, "config/app.json")
    if err != nil {
        return App{}, fmt.Errorf("读取应用配置: %w", err)
    }

    var app App
    // 解析失败与文件不存在要保留不同的错误上下文。
    if err := json.Unmarshal(data, &app); err != nil {
        return App{}, fmt.Errorf("解析应用配置: %w", err)
    }
    return app, nil
}

用 fstest.MapFS 准备可控的内存文件

MapFS 的键就是传给 Open 等方法的路径，值是 *fstest.MapFile。文件正文放在 Data 中；像本例这样使用 config/app.json 时，不必额外添加 config 父目录。

package config_test

import (
    "testing"

    "example.com/demo/config"
    "testing/fstest"
)

func TestLoadApp(t *testing.T) {
    // 测试数据只存在内存中，不依赖开发机上的 config 目录。
    fsys := fstest.MapFS{
        "config/app.json": &fstest.MapFile{
            Data: []byte(`{"name":"worker","port":8080}`),
        },
    }

    got, err := config.LoadApp(fsys)
    if err != nil {
        t.Fatalf("LoadApp() error = %v", err)
    }
    if got.Name != "worker" || got.Port != 8080 {
        t.Fatalf("LoadApp() = %#v, want worker:8080", got)
    }
}

func TestLoadAppMissing(t *testing.T) {
    // 空 MapFS 用来覆盖文件不存在，而不是创建一个空的临时文件。
    _, err := config.LoadApp(fstest.MapFS{})
    if err == nil {
        t.Fatal("LoadApp() error = nil, want missing file error")
    }
}

这里的断言验证了业务结果，而不是验证测试夹具的内部实现。需要模拟修改时间、目录或符号链接时，再给 MapFile 设置 ModTime、带有 fs.ModeDir 的 Mode，或把 Data 作为链接目标。

目录测试要注意 MapFS 的适用边界

父目录可以由路径推导出来，但“空目录”或需要精确元数据的目录应显式加入，例如 "config": &fstest.MapFile{Mode: fs.ModeDir}。如果业务调用 fs.ReadDir，要同时断言条目名称、排序和空目录行为，不要只测一个文件的读取。

MapFS 的操作直接读取 map，所以测试执行期间不要并发增删 map 项；否则会产生数据竞争。目录打开和读取还需要遍历整个 map，文件很多时会变慢，官方建议把它用于几百个以内的测试条目。大规模性能测试应换成真实文件系统或专门的测试环境。

用 fstest.TestFS 检查文件系统契约

如果你正在实现自己的 fs.FS，还可以调用 fstest.TestFS。它会遍历文件树并检查文件行为；传入的 expected 文件表示“至少应该存在”，而不是要求文件系统只能包含这些文件。符号链接不会被跟随，但实现了相关接口时，其 Lstat 信息也会被检查。

func TestMyFSContract(t *testing.T) {
    // expected 只表达最低要求，文件系统可以包含更多条目。
    if err := fstest.TestFS(myFS, "config/app.json"); err != nil {
        t.Fatal(err)
    }
}

实际项目可以把两类测试分开：LoadApp 的测试关注错误转换和业务字段；TestFS 关注自定义实现是否遵守打开、读取、目录和链接的公共约定。分开后，失败信息更容易定位。

常见问题

MapFS 能替代所有临时目录测试吗？

不能。它适合小规模、确定性的读文件和目录测试；需要验证权限、真实文件锁、磁盘空间或大量目录性能时，应使用真实文件系统。

为什么 MapFS 里没有写入接口？

MapFS 是面向测试读取的内存文件系统，业务写入逻辑应通过可替换的写入抽象或临时目录测试，不要把修改 map 当作生产文件写入。

TestFS 通过后业务测试还要写吗？

要写。TestFS 只证明文件系统行为基本合约成立，配置字段默认值、JSON 错误和缺失文件的业务结果仍需要单独断言。