测试函数应命名行为而非实现，如TestWhenThen模式；避免硬编码JSON等字符串，改用json.RawMessage复用；禁用全局状态修改；子测试需t.Run包裹并命名清晰；慎用共享资源与隐式耦合。
测试函数命名要体现行为而非实现
Go 的测试函数名常被写成 TestParseUser 或 TestUserParse，这类命名紧贴函数名，一旦重构 ParseUser 为 DecodeUser，测试名就过时。更稳妥的方式是描述「在什么条件下，发生什么行为」，比如 TestUserJSONParsingReturnsErrorOnInvalidField。虽然稍长，但能抵抗实现细节变更，也方便后续快速定位某类场景是否覆盖。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
Test模式（如When Then TestLoginHandlerWhenMissingPasswordThenReturns400） - 避免在测试名中出现具体函数名、结构体字段名或内部错误码
- 如果一个测试文件只测一个行为，可把共性提取到子测试（
t.Run），主函数名保留主题即可，例如TestLoginHandler
避免在测试中硬编码 JSON/YAML/SQL 字符串
直接拼接多行 JSON 字符串进测试用例，不仅难读，还极易因格式缩进、逗号遗漏、转义错误导致测试失败——这类失败和业务逻辑无关，纯粹是字符串维护成本高。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
json.RawMessage或yaml.Node预解析一次，复用给多个子测试 - 对固定输入，优先定义为变量并加注释说明其业务含义，例如：
validUserJSON := []byte(`{ "name": "alice", "age": 30 }`) - 需要校验结构时，用匿名 struct +
json.Unmarshal而非map[string]interface{}，避免运行时类型断言错误和字段遗漏
慎用 testmain 和全局 init 做测试前准备
在 func TestMain(m *testing.M) 或包级 init() 中启动数据库、HTTP 服务或修改全局变量，会让测试之间产生隐式依赖。单个测试跑通，但并行执行（go test -race -p=4）时可能 panic 或结果错乱。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个测试应独立 setup/cleanup：用
t.Cleanup关闭临时资源，用testify/suite或自定义setupTest函数封装重复逻辑 - 若必须共享资源（如内存 SQLite DB），用 sync.Once + 互斥锁初始化，并确保 cleanup 是幂等的
- 避免修改
os.Args、flag.Parse、log.SetOutput等影响其他测试的全局状态；改用局部flag.NewFlagSet或传参方式替代
表格驱动测试里别把断言逻辑塞进循环体
常见写法是把 assert.Equal 或 require.NoError 全部写在 for 循环里，导致某个 case 失败时，错误信息只显示「index 12 failed」，无法一眼看出是哪个输入组合出问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个子测试用
t.Run(name, func(t *testing.T))包裹，name应包含关键输入值（如fmt.Sprintf("input_%s_output_%v", tc.input, tc.want)） - 断言失败前打印上下文：
if !reflect.DeepEqual(got, tc.want) { t.Errorf("unexpected result for input %q: got %+v, want %+v", tc.input, got, tc.want) } - 复杂断言（如嵌套 map 比较）抽成独立函数，返回 human-readable diff，而不是依赖
reflect.DeepEqual的原始输出
