Go test 命令原生支持单元测试，无需额外框架；需满足文件名规范（xxx_test.go）、含Test开头函数、与被测代码同包；集成测试需手动管理依赖生命周期，推荐用TestMain统一初始化并显式清理资源。
Go test 命令默认就支持单元测试，无需额外“搭建环境”
很多人误以为 Go 需要像 Java 那样配 Maven、JUnit 或 Python 那样装 pytest 才能测——其实 go test 是 Go 工具链原生命令，只要项目结构合规（xxx_test.go 文件放在包目录下），直接运行就能跑。不需要安装第三方测试框架，也不用写 main 函数或启动服务。
常见错误现象：go test 报 no buildable Go source files，通常是因为：
-
*_test.go文件里没定义任何以Test开头的函数（如func TestAdd(t *testing.T)） - 文件名拼错，比如写成
test_add.go（缺下划线）或add_test.g0（拼写错误） - 测试文件和被测代码不在同一包，且没用
import正确引入（Go 要求测试文件和源码在同一个包，除非是外部集成测试）
集成测试需手动控制依赖生命周期，比如启动/关闭 mock 数据库
单元测试应隔离外部依赖；集成测试则要模拟真实协作场景，比如连接 SQLite 临时文件、起一个本地 HTTP server、或用 testcontainers-go 拉 PostgreSQL 容器。关键不是“怎么搭”，而是“谁负责启停”。
推荐做法：用 TestMain 统一管理共享资源，避免每个测试都重复初始化：
立即学习“go语言免费学习笔记（深入）”；
func TestMain(m *testing.M) {
db, _ := sql.Open("sqlite3", ":memory:")
defer db.Close()
// 设置全局测试 DB 实例
testDB = db
os.Exit(m.Run())
}
注意点：
GInstall OneClick — 一键安装 GitHub 项目：规划、克隆、安装 Node 依赖、运行开发脚本。适用于想要获取 GitHubNode.js 项目的用户。
-
TestMain不会自动继承子测试的*testing.T，不能在里面调用t.Fatal，出错要用os.Exit(1) - 如果用了容器（如
testcontainers-go），务必在defer或TestMain结尾显式container.Terminate()，否则 CI 环境可能堆积僵尸容器 - 不要在
init()函数里初始化数据库连接——它在TestMain之前执行，无法捕获 setup 失败
区分 -short 和 -race 标志的实际用途，别滥用
go test -short 不是“快速模式”，而是约定俗成的“跳过耗时测试”的开关；go test -race 是开启竞态检测，二者解决完全不同的问题。
典型误用：
- 把网络请求、文件读写、sleep 等操作放在未加
if testing.Short()的测试里 → 导致 CI 超时 - 本地开发时没加
-race，上线后出现偶发 panic，却归因为“测试没覆盖” - 在 GitHub Actions 中只跑
go test ./...，漏掉-race和-cover→ 隐患长期潜伏
建议 CI 脚本至少包含两轮：
go test -short ./... go test -race -short ./...
测试覆盖率报告容易误导，重点关注分支而非行数
go test -coverprofile=c.out && go tool cover -html=c.out 生成的 HTML 报告，显示“95% 行覆盖”不代表逻辑安全。Go 的 if/else、switch、错误路径经常被忽略。
真正该盯住的是：
- 所有
err != nil分支是否都有对应测试（比如磁盘满、网络超时、JSON 解析失败） - HTTP handler 中
if r.Method != "POST"这类守卫逻辑有没有被触发 - 使用
gomock或mockgen时，是否验证了方法调用次数和参数内容，而不仅是“有没有调”
一个常被忽略的细节：go test 默认不统计测试文件自身（*_test.go）的覆盖率，所以报告里的百分比只反映业务代码——但如果你在测试文件里写了大量工具函数（比如 setupDB()），它们实际影响测试稳定性，却完全不在报告中体现。
