测试工具函数应放在同包的helper_test.go中，使用与被测包一致的package名；需加t.Helper()，参数精简，失败用t.Fatal；外部依赖通过结构体封装状态；仅复用语义稳定、调用频繁、副作用可控的逻辑。
测试工具函数该放在哪里
Go 测试代码复用的核心矛盾是：测试辅助函数不能被生产代码 import，但又需要被多个 *_test.go 文件使用。最稳妥的做法是把工具函数定义在同包的 helper_test.go（注意后缀仍是 _test.go）中，并且**不声明 package 名为 xxx_test**，而是保持和被测包一致的 package 名（例如被测包是 user，工具函数就写在 package user 下）。这样其他 *_test.go 文件就能直接调用，又不会污染生产构建。
常见错误是新建一个 testutil 包——它会导致循环 import 或测试二进制体积膨胀；也别把工具函数塞进某个具体测试文件里，否则无法跨文件复用。
如何设计可传参、易断言的测试工具函数
工具函数不是越“通用”越好，而是要贴合真实测试场景。比如构造测试用户，与其写一个返回 map[string]interface{} 的函数，不如直接返回 *user.User 并接受必要字段作为参数：
func NewTestUser(t *testing.T, name, email string) *user.User {
t.Helper() // 标记为测试辅助函数，失败时定位到调用行而非函数内
return &user.User{
ID: 1,
Name: name,
Email: email,
}
}
关键点：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
t.Helper()必须加，否则t.Errorf报错会指向工具函数内部而不是测试用例 - 参数只传真正影响行为的字段，避免 “全字段传参” 导致调用冗长
- 如果工具函数内部有校验（如邮箱格式），失败时应调用
t.Fatal或t.Fatalf，而不是返回 error —— 测试函数本就不该处理错误分支
数据库/HTTP 依赖怎么安全复用
带外部依赖的复用逻辑最容易出问题。不要在工具函数里硬编码连接字符串或启动全局 server，而应通过闭包或结构体封装状态：
例如复用测试用内存 SQLite：
type TestDB struct {
DB *sql.DB
}
func NewTestDB(t *testing.T) *TestDB {
db, err := sql.Open("sqlite3", ":memory:")
if err != nil {
t.Fatal(err)
}
return &TestDB{DB: db}
}
func (td *TestDB) MustExec(t *testing.T, query string, args ...any) {
_, err := td.DB.Exec(query, args...)
if err != nil {
t.Fatal(err)
}
}
这样每个测试用例拿自己的 *TestDB 实例，互不干扰。如果强行用全局变量或 init 函数初始化 DB，会引发并发测试 panic 或状态残留。
什么时候不该复用——避免过度抽象
不是所有重复代码都值得抽成工具函数。以下情况建议保留原样：
- 仅在一个测试文件中出现 2 次的简单 setup（如两次
bytes.NewReader([]byte("foo"))） - 逻辑随测试用例高度变化（比如每次 mock 行为都不同），抽成函数反而增加理解成本
- 涉及
defer或临时文件清理的逻辑，复用后容易漏掉 cleanup 或 defer 错位
真正值得复用的是那些「语义稳定、调用频繁、副作用可控」的模式，比如构造固定结构体、发起标准 HTTP 请求、初始化带预设数据的存储实例。抽象的边界，往往就在「改一个参数就能覆盖 80% 场景」那条线上。
