应替换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 设计为可注入依赖,或用接口隔离。
bytes.Buffer 的 mock loggerlog.New(os.Stderr, ...) —— 它把输出绑定死,无法在测试中拦截type Service struct {
logger *log.Logger
}
func NewService() *Service {
return &Service{
logger: log.New(os.Stde
rr, "", 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
shortfile 输出不一致多个 goroutine 同时写同一个 bytes.Buffer 会引发 panic(Buffer 非并发安全)。即使测试本身是单 goroutine,被测逻辑也可能启动后台协程打日志。
sync.Mutex 包裹 Buffer.Write(),或改用 io.MultiWriter + 单独锁testify/mock 或自定义 io.Writer 实现线程安全写入-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()
defer b.mu.Unlock()
return b.buf.String()
}
日志测试真正难的不是“怎么捕获”,而是“怎么设计才能让日志可测”——一旦 logger 被硬编码或封装过深,后续补测试的成本远高于初期留个接口。