如何在Go代码中测试filepath.Abs调用失败的场景？

这类测试是否必要？ #

有必要。如果你的业务逻辑明确要求在filepath.Abs失败时返回指定的自定义错误，覆盖这些错误分支能确保：

• 错误返回的类型/信息符合预期，不会出现漏处理导致的panic或模糊错误
• 后续业务逻辑不会因未处理的路径异常引发连锁问题
• 团队协作时，能明确这些异常场景的处理规则

除了依赖注入，还有哪些可行方法？ #

1. 包级函数变量打桩

在业务代码所在包中定义一个指向filepath.Abs的包级变量，测试时替换这个变量为返回错误的mock函数，无需修改结构体：

业务代码修改：

package myservice

import "path/filepath"

// 定义包级变量，默认绑定filepath.Abs
var absFunc = filepath.Abs

func (s *service) myFunc(path string) error {
    dir := s.Component().Dir()
    absDir, err := absFunc(dir)

    if err != nil {
        return my_errors.NewFailedToGetAbsoluteComponentDir()
    }

    absPath, err := absFunc(path)
    if err != nil {
        return my_errors.NewFailedToGetAbsPath()
    }

    // more code...
    return nil
}

测试代码示例：

package myservice

import (
    "errors"
    "testing"

    "github.com/stretchr/testify/assert"
)

func TestMyFunc_AbsDirFailed(t *testing.T) {
    // 保存原函数，测试后恢复，避免影响其他测试
    originalAbs := absFunc
    defer func() { absFunc = originalAbs }()

    // 替换为返回错误的mock函数
    absFunc = func(_ string) (string, error) {
        return "", errors.New("mock abs failure")
    }

    s := &service{/* 初始化你的service实例 */}
    err := s.myFunc("any-path")

    assert.ErrorIs(t, err, my_errors.NewFailedToGetAbsoluteComponentDir())
}

func TestMyFunc_AbsPathFailed(t *testing.T) {
    originalAbs := absFunc
    defer func() { absFunc = originalAbs }()

    // 控制两次调用的返回结果：第一次成功，第二次失败
    callCount := 0
    absFunc = func(_ string) (string, error) {
        callCount++
        if callCount == 2 {
            return "", errors.New("mock path abs failure")
        }
        return "/fake/valid/path", nil
    }

    s := &service{/* 初始化service实例 */}
    err := s.myFunc("test-path")

    assert.ErrorIs(t, err, my_errors.NewFailedToGetAbsPath())
}

2. Mock Component返回无效路径

如果Component().Dir()返回的路径是导致filepath.Abs失败的唯一原因，可以mockComponent的返回值，让它返回一个肯定会触发filepath.Abs失败的路径（比如包含系统不允许的特殊字符，如\x00）。但这种方法依赖操作系统的路径规则，测试稳定性差，不推荐作为主要方案。

方法对比 #

• 包级变量打桩：实现简单，无需修改结构体，适合小型项目或快速验证；但要注意并发测试时的全局变量冲突，需在每个测试后恢复原函数。
• 依赖注入：符合依赖倒置原则，代码结构更清晰，大型项目中更易维护，并发测试无冲突；但需要修改结构体定义，引入额外的依赖字段。

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