Go test 文件怎么用 gotestsum 自动生成？
gotestsum 不生成测试逻辑，只帮你跑测试并美化输出。想自动生成 xxx_test.go 文件里的测试函数，它完全不干这事——别被名字误导。
常见错误现象：gotestsum -- -run TestFoo 跑不通，因为压根没写 TestFoo 函数；或者误以为加了 --generate 参数就能产出测试代码（它根本没有这个 flag）。
- 真实用途：替代
go test做持续集成中的测试执行器，带失败高亮、历史对比、JSON 输出等 - 安装后直接当
go test用：gotestsum -- -count=1 -race - 和模板生成无关，不读源码结构，也不分析函数签名
用 gomock 或 counterfeiter 自动生成 mock 测试依赖？
它们能生成 mock 结构体和方法，但不是“测试用例”，而是帮你补上 mock_xxx.go 里缺失的依赖桩。真正要测的 TestXXX 还得手写。
使用场景：接口多、依赖外部服务（如数据库、HTTP client）、想隔离单元测试边界。
立即学习“go语言免费学习笔记（深入）”；
-
gomock需先定义 interface，再用mockgen生成：mockgen -source=service.go -destination=mocks/service_mock.go -
counterfeiter更轻量，直接针对已有类型生成：counterfeiter -o mocks/db_mock.go . Database - 注意：生成的 mock 默认不带行为逻辑，
Call.Do()或Return()还得在测试里手动配 - 兼容性风险：Go 1.21+ 的泛型 interface 可能导致
mockgen解析失败，需加-package显式指定
template 包真能生成测试函数？怎么写安全？
能，但得自己搭骨架。Go 的 text/template 或 html/template 是通用模板引擎，不内置“测试生成规则”，你得提供数据结构 + 模板文本，才能产出合法 Go 代码。
容易踩的坑：生成的代码语法错、包名冲突、测试函数名重复、没 import 依赖包。
- 模板里必须严格遵循 Go 语法：函数名以
Test开头，参数是*testing.T，结尾换行不能少 - 示例模板片段：
func Test{{.FuncName}}(t *testing.T) { got := {{.Pkg}}.{{.FuncName}}({{.Args}}) if got != {{.Want}} { t.Errorf("expected %v, got %v", {{.Want}}, got) } } - 渲染前务必校验
.FuncName是否符合 Go 标识符规则（不能含空格、数字开头等），否则生成文件无法go build - 生成路径建议用
_test.go后缀，并确保和待测代码在同一个 module 下，否则go test找不到
为什么不用 gofuzz 或 quickcheck 类工具？
它们不生成测试用例代码，而是运行时动态构造输入值做 property-based testing。你看到的是一堆随机字符串、整数、结构体实例，不是写进文件的 TestXXX 函数。
适用场景：验证函数是否满足不变式（如“反转两次等于原值”），而非补全覆盖率缺口。
-
gofuzz专注随机填充 struct，适合 API 请求体模糊测试，但不会为你生成TestUnmarshalJSON -
quickcheck风格需手动定义Prop和Arbitrary实现，调试成本高，且失败用例不落地为可复现的测试文件 - 性能影响明显：每次运行都重新生成输入，CI 中难复现、难归档；而静态生成的测试文件可 git track、code review
最常被忽略的一点：模板生成的测试代码一旦产出，就和源码一样需要维护。函数签名变了、业务逻辑调了，那些自动生成的 TestXXX 很可能 silently 失效——没人会 audit 一堆模板吐出来的文件是否还匹配当前实现。
