Golang测试代码如何提升可维护性

测试函数应命名行为而非实现，如TestWhenThen模式；避免硬编码JSON等字符串，改用json.RawMessage复用；禁用全局状态修改；子测试需t.Run包裹并命名清晰；慎用共享资源与隐式耦合。

测试函数命名要体现行为而非实现

Go 的测试函数名常被写成 TestParseUser 或 TestUserParse，这类命名紧贴函数名，一旦重构 ParseUser 为 DecodeUser，测试名就过时。更稳妥的方式是描述「在什么条件下，发生什么行为」，比如 TestUserJSONParsingReturnsErrorOnInvalidField。虽然稍长，但能抵抗实现细节变更，也方便后续快速定位某类场景是否覆盖。

实操建议：

• 用 TestWhenThen 模式（如 TestLoginHandlerWhenMissingPasswordThenReturns400）
• 避免在测试名中出现具体函数名、结构体字段名或内部错误码
• 如果一个测试文件只测一个行为，可把共性提取到子测试（t.Run），主函数名保留主题即可，例如 TestLoginHandler

避免在测试中硬编码 JSON/YAML/SQL 字符串

直接拼接多行 JSON 字符串进测试用例，不仅难读，还极易因格式缩进、逗号遗漏、转义错误导致测试失败——这类失败和业务逻辑无关，纯粹是字符串维护成本高。

实操建议：

• 用 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 或结果错乱。

实操建议：

• 每个测试应独立 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」，无法一眼看出是哪个输入组合出问题。

实操建议：

• 每个子测试用 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 的原始输出

测试可维护性的最大敌人不是代码量，而是「改一处，查三处」的隐式耦合——比如一个 mock 行为被五个测试共享，或者一个 JSON 样本被复制粘贴到三个文件里。保持测试与生产代码同等的抽象层级和边界意识，比追求覆盖率数字更重要。