Go中仅进程可见的临时文件系统及CLI应用测试问题

1. 用编程方式替代shell命令是否更妥当？ #

必须换。直接调用shell命令有几个硬伤：

• 跨平台兼容性差：Windows和Linux的文件操作命令语法差异大（比如copy vs cp、rmdir /s/q vs rm -rf），测试代码会变得混乱且难以维护。
• 错误处理繁琐：shell命令的退出码、输出捕获在Go里需要额外处理，不如标准库函数直接返回error直观可控。
• 环境依赖强：shell命令的执行依赖系统PATH、权限等配置，容易出现本地正常但CI环境失败的不一致问题。

Go标准库os、io、path/filepath已经覆盖了你需要的所有操作，示例代码如下：

import (
    "io"
    "os"
)

// 创建递归目录
if err := os.MkdirAll("./test-dir", 0755); err != nil {
    t.Fatal(err)
}

// 模拟touch创建空文件
f, err := os.Create("./test-file.txt")
if err != nil {
    t.Fatal(err)
}
f.Close()

// 复制文件
src, err := os.Open("./src.txt")
if err != nil {
    t.Fatal(err)
}
defer src.Close()
dst, err := os.Create("./dst.txt")
if err != nil {
    t.Fatal(err)
}
defer dst.Close()
if _, err := io.Copy(dst, src); err != nil {
    t.Fatal(err)
}

// 移动文件
if err := os.Rename("./src.txt", "./new-src.txt"); err != nil {
    t.Fatal(err)
}

// 删除文件/目录
if err := os.RemoveAll("./test-dir"); err != nil {
    t.Fatal(err)
}

2. 是否存在仅当前进程可见的临时文件系统？ #

有两种可靠的隔离方案：

方案一：标准库临时目录（推荐用于E2E测试） #

用os.MkdirTemp创建唯一临时目录，每个测试用例在独立目录中操作，测试结束后自动清理。这种方式跨平台兼容，无需额外依赖，且支持测试并行执行。

示例：

func TestMyCLI(t *testing.T) {
    // 创建唯一临时目录，前缀可自定义方便排查问题
    tempDir, err := os.MkdirTemp("", "mycli-test-")
    if err != nil {
        t.Fatal(err)
    }
    // 确保测试结束后删除临时目录（无论成功失败）
    defer os.RemoveAll(tempDir)

    // 切换到临时目录执行操作，避免路径混乱
    originalDir, err := os.Getwd()
    if err != nil {
        t.Fatal(err)
    }
    defer os.Chdir(originalDir)
    if err := os.Chdir(tempDir); err != nil {
        t.Fatal(err)
    }

    // 在此执行CLI测试，所有文件操作都在独立的tempDir中，不会互相干扰
}

方案二：内存文件系统（适合单元测试） #

借助github.com/spf13/afero库的MemMapFs，完全在内存中模拟文件系统，所有操作不落地磁盘，进程退出后自动销毁。但如果是直接调用CLI二进制的E2E测试，需要CLI本身支持注入文件系统，否则临时目录方案更直接。

示例：

import "github.com/spf13/afero"

func TestMyCLIMemFS(t *testing.T) {
    fs := afero.NewMemMapFs()

    // 创建目录
    if err := fs.MkdirAll("/test-dir", 0755); err != nil {
        t.Fatal(err)
    }

    // 创建文件
    f, err := fs.Create("/test-file.txt")
    if err != nil {
        t.Fatal(err)
    }
    f.Close()

    // 通过依赖注入让CLI使用该内存FS执行操作
}

3. 互斥锁是否应该用？ #

不推荐。原因如下：

• 大幅拖慢构建：CI环境依赖并行测试提升效率，加互斥锁后所有测试串行执行，会显著增加构建时间。
• 未解决根本问题：互斥锁只是掩盖了冲突，没有实现测试用例的真正隔离，若测试存在其他全局状态依赖，仍会出现隐性bug。
• 可靠性差：如果测试中途崩溃，互斥锁可能无法正确释放，导致后续测试卡住。

正确做法是让每个测试用例完全隔离，用临时目录或内存FS实现，既支持并行执行，又能彻底避免文件操作干扰。

额外建议 #

• 开启测试并行：在测试函数中加入t.Parallel()，配合临时目录可大幅提升CI测试速度。
• 避免硬编码路径：所有文件操作基于临时目录的绝对路径，不要依赖当前工作目录的全局状态。
• 强制资源清理：用defer确保临时目录无论测试结果如何都会被删除，避免CI环境磁盘被冗余文件占满。

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