Go单元测试如何mock调用io.Copy的函数 解决测试挂起问题

测试永久挂起的核心原因是自定义的mockReadCloser违反了io.Reader接口的约定，导致io.Copy进入无限死循环：

• io.Reader接口明确规定：当Read(p []byte)返回0, nil时，不代表数据流结束，仅表示本次没有读到任何数据，调用方（也就是io.Copy）会立刻再次调用Read尝试读取数据，无限重复这个过程就会出现永久挂起的现象。
• 猜测的「空数据拷贝到空写入端」是错误的，传os.Stdout仍然复现问题也能佐证：故障点和写入端无关，完全出在读取端的Mock实现错误。
• 额外说明：编写的mockWriteCloser的Write方法同样违反io.Writer约定：无论传入多少写入内容都返回0, nil，按照接口规则如果返回的写入字节数小于传入切片长度，必须同时返回非nil错误，否则io.Copy也会进入写入重试的死循环，只是当前代码先卡在读取端的死循环，没有触发这个问题而已。

io.Copy的终止条件只有两个：

• 读取端返回io.EOF错误（代表数据流全部读完，正常结束）
• 读取或者写入过程中返回了非io.EOF的其他错误（异常终止）

不要手写不符合接口约定的Mock，优先使用Go标准库提供的现成工具实现测试桩，完全避免接口契约违反的问题：

• 读取端（io.ReadCloser）：用io.NopCloser包装现成的Reader即可，比如io.NopCloser(strings.NewReader("测试写入内容"))，标准库实现会在内容读完后自动返回io.EOF，完全符合接口要求
• 写入端（io.WriteCloser）：可以基于bytes.Buffer封装，Buffer本身已经实现了标准的Write方法，只需要补充一个无操作的Close方法即可。

如果需要模拟读错误、写错误等异常场景，再自定义Mock即可，自定义时必须严格遵守接口约定：

• Read方法：正常读完所有内容时返回0, io.EOF；出现错误时返回对应错误；读到部分内容时返回读取到的字节数+nil
• Write方法：写入成功时返回len(b), nil；写入失败时返回实际写入字节数+对应错误，禁止返回小于len(b)的字节数同时返回nil错误

修正后的测试代码示例 #

package main

import (
	"bytes"
	"errors"
	"io"
	"strings"
	"testing"
)

// 正常场景用的WriteCloser实现，内部用buffer存储写入内容方便校验
type testWriteCloser struct {
	buf *bytes.Buffer
}

func (t *testWriteCloser) Write(b []byte) (int, error) {
	return t.buf.Write(b)
}

func (t *testWriteCloser) Close() error {
	return nil
}

// 模拟读异常的ReadCloser
type errReadCloser struct {
	err error
}

func (e *errReadCloser) Read(p []byte) (int, error) {
	return 0, e.err
}

func (e *errReadCloser) Close() error {
	return nil
}

// 模拟写异常的WriteCloser
type errWriteCloser struct {
	err error
}

func (e *errWriteCloser) Write(b []byte) (int, error) {
	return 0, e.err
}

func (e *errWriteCloser) Close() error {
	return nil
}

func Test_writeFile(t *testing.T) {
	testContent := "test s3 file content"
	tests := []struct {
		name        string
		destination io.WriteCloser
		source      io.ReadCloser
		wantErr     bool
		wantContent string
	}{
		{
			name:        "normal copy success",
			destination: &testWriteCloser{buf: &bytes.Buffer{}},
			source:      io.NopCloser(strings.NewReader(testContent)),
			wantErr:     false,
			wantContent: testContent,
		},
		{
			name:        "read error return err",
			destination: &testWriteCloser{buf: &bytes.Buffer{}},
			source:      &errReadCloser{err: errors.New("s3 read failed")},
			wantErr:     true,
		},
		{
			name:        "write error return err",
			destination: &errWriteCloser{err: errors.New("file write failed")},
			source:      io.NopCloser(strings.NewReader(testContent)),
			wantErr:     true,
		},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			err := writeFile(tt.destination, tt.source)
			if (err != nil) != tt.wantErr {
				t.Errorf("writeFile() error = %v, wantErr %v", err, tt.wantErr)
				return
			}
			// 正常场景校验写入内容是否符合预期
			if !tt.wantErr {
				if twc, ok := tt.destination.(*testWriteCloser); ok {
					if twc.buf.String() != tt.wantContent {
						t.Errorf("write content got = %v, want %v", twc.buf.String(), tt.wantContent)
					}
				}
			}
		})
	}
}

• 实现标准库的io相关接口时，一定要先通读接口文档的约定，不要只看方法签名就随意写实现，这类隐式契约违反导致的死循环、静默错误非常难排查
• 单测场景优先复用标准库的组件搭建测试桩，比自己从零写Mock出错概率低很多

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