单元测试验证函数逻辑，集成测试检查服务协作。单元测试使用testing库编写测试用例，通过interface mock外部依赖，关注核心逻辑覆盖率；集成测试准备真实环境，测试端到端流程，使用testmain初始化资源并确保测试无副作用；测试代码应与源码同目录，按功能命名文件，并区分单元与集成测试的命名或标签。
在Go语言开发的微服务项目中，测试是保障代码质量、提升交付可靠性的关键环节。单元测试和集成测试各司其职：前者验证函数或模块逻辑是否正确，后者检查多个服务或组件之间协作是否正常。两者结合，才能构建出健壮的服务系统。
单元测试怎么做？
单元测试的核心在于隔离性，即不依赖外部环境（如数据库、网络请求），只关注当前函数本身的逻辑是否正确。
-
使用标准库testing：Go自带的
testing包足够应对大多数场景，通过func TestXxx(t *testing.T)定义测试用例。 - mock外部依赖：比如调用第三方接口或者访问数据库的方法，可以使用interface抽象，并在测试中注入假数据。
- 覆盖率优先但不过度追求：100%覆盖不一定代表高质量，重点应放在核心业务逻辑上。
- 示例：
func TestAdd(t *testing.T) {
result := add(2, 3)
if result != 5 {
t.Errorf("Expected 5, got %d", result)
}
}写单元测试时尽量让每个测试函数只测一个行为，这样失败时更容易定位问题。
立即学习“go语言免费学习笔记（深入）”；
集成测试怎么设计？
集成测试更贴近真实运行环境，通常会涉及数据库、缓存、其他微服务等组件之间的交互。这类测试的目标是确保整个流程没有问题。
- 准备真实环境：可以启动一个临时数据库，或者连接本地docker容器中的中间件。
- 测试端到端流程：比如从HTTP请求入口出发，走完整个业务链路，最后验证结果是否符合预期。
- 使用testmain初始化资源：可以在所有测试执行前做一些准备工作，比如连接数据库、初始化配置。
- 避免副作用：测试之间要相互独立，不能互相干扰，建议使用事务回滚或清理脚本。
举个例子，你可以写一个测试用例来模拟用户注册流程：
- 发送POST请求到
/register - 检查返回状态码是否为200
- 查询数据库确认用户是否被创建
这种测试虽然执行时间比单元测试长，但在CI/CD流程中非常有必要定期运行。
如何组织测试代码结构？
合理的目录结构有助于团队维护和持续集成自动化：
-
与源码放在一起：Go推荐将
xxx_test.go文件放在与被测代码相同的目录下。 -
按功能划分测试文件：比如
user_service_test.go、payment_handler_test.go等。 -
区分单元与集成测试：可以通过命名约定，例如
unit_*.go和integration_*.go，或者使用build tag进行标记过滤。
如果你希望CI系统只跑部分测试，可以用 -v -run=TestXXX 或者 build tags 来控制范围。
基本上就这些。写好测试不是一蹴而就的事，但只要坚持做下去，你会发现它带来的好处远大于成本。
