应显式构造失败条件使函数真实进入错误分支，优先用真实依赖（如内存map）触发错误，mock时确保error类型和值与生产一致，并在table-driven测试中分离wanterr与wanterris，t.run命名需包含具体error类型。
怎么写能覆盖 error 返回路径的测试用例
直接测 err != nil 不够，得让被测函数真走到出错分支。常见错误是 mock 失败逻辑不到位，比如用 io.EOF 冒充业务错误，但函数内部却只检查 errors.Is(err, mypkg.ErrNotFound)，结果测试永远不触发目标分支。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用真实依赖（如内存 map 替代数据库）构造失败条件，比如查一个不存在的 key 让
GetUser()返回ErrUserNotFound - 如果必须 mock，确保返回的 error 类型和值与生产代码一致：用
errors.New("xxx")或fmt.Errorf("xxx: %w", ErrX)，别用nil或空字符串占位 - 对自定义 error 类型，检查是否实现了
Unwrap()和Error()，否则errors.Is()可能失效
Table-driven test 怎么组织 error 场景
把 error 测试硬塞进 table 结构里，容易让 case 表达模糊——比如 “should return error when user ID is empty” 和 “should return ErrInvalidID when user ID is empty” 是两回事：前者只关心非 nil，后者要求具体类型。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个
testcase显式声明期望的 error：用wantErr: true+wantErrIs: ErrInvalidID两字段分离“是否出错”和“错成什么样” - 避免在 table 中用
err.Error()做断言，字符串匹配脆弱；改用errors.Is(err, tc.wantErrIs)或errors.As(err, &e) - 为 error 场景单独建表，或至少用注释标记：
// error case: empty ID，别和正常流程混在同一张表里
为什么 t.Run() 名字里要包含 error 类型
当 12 个 table case 全挂掉，你点开 TestGetUser/empty_ID 还是得手动翻源码看它到底该返回啥 error。名字不含 error 信息，等于放弃第一层调试线索。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
t.Run()名字写成"empty_id_returns_ErrInvalidID"，而不是"empty_id" - 如果 error 类型动态生成（如带状态码），至少保留关键标识：
"not_found_returns_404" - CI 日志里 grep
ErrValidation能立刻定位所有相关失败用例，名字就是索引
defer cleanup 在 error 测试中容易漏掉什么
测试函数中途 panic 或提前 return，defer 不执行，导致资源残留、端口占用、临时文件堆积——尤其在集成测试里调了真实 HTTP server 或打开了文件。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有外部资源初始化后立刻 defer 清理，哪怕当前 case 看起来“不会走到那里”
- 不用
defer f.Close()，改用defer func() { _ = f.Close() }()避免 close 报错干扰主 error 断言 - 对并发测试，清理逻辑加锁或用 sync.Once，防止多个 goroutine 同时删同一临时目录
error 测试最难的不是写断言，而是让失败时你能一眼看出是“函数逻辑错了”，还是“测试 setup 漏了 cleanup”，或是“mock 返回的 error 类型不对”。这三个地方出问题，日志长得一模一样。
