如何使用Golang测试日志输出_Golang log包单元测试方法

应替换log输出目标为bytes.Buffer并恢复原输出，对自定义logger需依赖注入，禁用Lshortfile等易变flag，并发时用sync.Mutex保护Buffer。

如何捕获 log.Printf 等标准日志输出做断言

Go 标准库的 log 包默认输出到 os.Stderr，无法直接断言内容。必须替换其输出目标为内存缓冲区（如 bytes.Buffer），再读取验证。

• 调用 log.SetOutput() 在测试前重定向输出，测试后务必恢复原输出（否则影响其他测试）
• 不要在测试中调用 log.SetFlags(0) 以外的 flag 修改——时间戳、文件名等额外字段会让断言脆弱
• 若被测函数内部新建了独立 *log.Logger（非使用 log.Printf），则需通过参数注入或接口抽象，不能靠 log.SetOutput()

func TestMyFunc_LogsError(t *testing.T) {
    var buf bytes.Buffer
    oldOut := log.Writer()
    log.SetOutput(&buf)
    defer log.SetOutput(oldOut) // 关键：必须恢复

    MyFunc() // 触发 log.Printf("failed: %v", err)

    output := buf.String()
    if !strings.Contains(output, "failed:") {
        t.Errorf("expected log to contain 'failed:', got %q", output)
    }
}

测试自定义 *log.Logger 实例的输出

当代码使用 log.New() 创建私有 logger（比如作为结构体字段），log.SetOutput() 不起作用。此时应把 logger 设计为可注入依赖，或用接口隔离。

• 推荐方式：将 logger 作为参数传入函数，或通过 struct 字段接收，测试时传入带 bytes.Buffer 的 mock logger
• 不推荐硬编码 log.New(os.Stderr, ...) —— 它把输出绑定死，无法在测试中拦截
• 如果必须保留字段初始化，可用导出字段 + 测试时直接赋值覆盖（仅限包内测试）

type Service struct {
    logger *log.Logger
}

func NewService() *Service {
    return &Service{
        logger: log.New(os.Stderr, "", log.LstdFlags),
    }
}

func (s *Service) DoWork() {
    s.logger.Println("work started")
}

// 测试写法：
func TestService_DoWork(t *testing.T) {
    var buf bytes.Buffer
    s := &Service{
        logger: log.New(&buf, "", 0), // 关闭所有 flag，只留消息体
    }
    s.DoWork()
    if got := buf.String(); got != "work started\n" {
        t.Errorf("unexpected log: %q", got)
    }
}

避免因 log.Lshortfile 导致测试不稳定

启用 log.Lshortfile 后，日志会自动附加 file:line，而行号在重构时极易变动，导致字符串断言频繁失败。

• 单元测试中一律禁用 log.Lshortfile 和 log.Llongfile
• 若必须验证日志格式（如结构化日志），改用正则提取关键字段，而非全量字符串匹配
• CI 环境中尤其注意：不同 GOPATH 或模块路径可能让 shortfile 输出不一致

并发场景下日志捕获的注意事项

多个 goroutine 同时写同一个 bytes.Buffer 会引发 panic（Buffer 非并发安全）。即使测试本身是单 goroutine，被测逻辑也可能启动后台协程打日志。

• 最简单方案：用 sync.Mutex 包裹 Buffer.Write()，或改用 io.MultiWriter + 单独锁
• 更稳妥做法：改用 testify/mock 或自定义 io.Writer 实现线程安全写入
• 警惕 race detector 报告：运行测试时加上 -race 参数，能提前发现这类问题

type safeBuffer struct {
    mu  sync.Mutex
    buf bytes.Buffer
}

func (b *safeBuffer) Write(p []byte) (int, error) {
    b.mu.Lock()
    defer b.mu.Unlock()
    return b.buf.Write(p)
}

func (b *safeBuffer) String() string {
    b.mu.Lock()
    def
er b.mu.Unlock()
    return b.buf.String()
}

日志测试真正难的不是“怎么捕获”，而是“怎么设计才能让日志可测”——一旦 logger 被硬编码或封装过深，后续补测试的成本远高于初期留个接口。