单元测试、集成测试和端到端测试的边界如何划分

单元测试、集成测试和端到端测试并不是按“测试文件放在哪里”来区分，而是看这次测试要证明什么、允许哪些依赖进入。一个实用的判断是：只验证进程内规则就用单元测试；要验证真实数据库、消息队列或 HTTP 适配器就用集成测试；要证明用户从入口到结果的完整链路，再保留端到端测试。

测试边界的核心不是追求某一种测试数量，而是让每个风险由合适的依赖范围来承担。

Go 官方工具链把以 _test.go 结尾的文件交给 go test 执行，测试函数通常写成 TestXxx(*testing.T)。这解决的是“怎么运行”，不自动决定“应该测哪一层”。

先看三类测试真正隔离的对象

把被测对象放在中间，向外数依赖最容易判断边界。单元测试只让一个函数或小组件面对内存输入，外部仓储、时钟、随机数都可以通过接口替身控制；失败时通常能直接落到一条业务规则。

集成测试把某个真实边界接进来，例如让仓储适配器连接临时数据库，或让 HTTP 客户端调用测试服务。它验证的是序列化、SQL、事务、超时和协议契约，不适合覆盖所有排列组合。

端到端测试则从公开入口开始，经过鉴权、路由、业务服务、数据库和消息投递，检查一条关键业务是否真的闭环。它的诊断成本最高，所以应聚焦下单成功、支付回调、权限拒绝等少量主路径和高风险路径。

把测试层级落到一个订单服务

假设订单服务有三个对象：计算折扣的 pricing rule、保存订单的 repository adapter，以及接收请求的 order API。先问每个测试要隔离什么：

这样设计后，金额计算不必启动数据库；仓储测试不会重复验证全部 HTTP 路由；端到端测试也不需要把每种折扣组合重新跑一遍。分层的价值是缩小失败范围，而不是制造三套重复断言。

用 Go 的测试包把边界写出来

纯规则可以直接用表驱动测试。代码中的中文注释说明了输入和失败信息，便于把边界条件留在最靠近规则的位置：

func TestDiscount(t *testing.T) {
	// 表格集中放正常、临界和非法输入，避免只测一个示例。
	tests := []struct {
		name  string
		price int
		want  int
	}{
		{"普通订单", 100, 90},
		{"零金额", 0, 0},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			// 失败时同时打印输入和期望值，缩短定位路径。
			if got := discount(tt.price); got != tt.want {
				t.Fatalf("discount(%d) = %d, want %d", tt.price, got, tt.want)
			}
		})
	}
}

如果测试只依赖导出的行为，可以使用 package orders_test，让测试像外部调用方一样工作；需要检查未导出细节时才放在同一个 package。二者不是“单元与集成”的同义词，而是可见性边界。

集成与端到端测试的边界控制

集成测试应显式管理数据。每个测试准备自己的记录，使用事务回滚或临时 schema 清理，避免前一个测试污染后一个测试；连接、文件和临时目录要在测试结束时释放。若只想检查 HTTP 编解码而不接真实网络，可以使用 httptest，但这仍然只是组件级验证，不应宣称覆盖线上链路。

端到端测试的断言也要克制：断言用户能观察到的状态码、订单状态和关键事件即可，内部日志格式不应成为端到端契约。遇到偶发失败时，先记录请求标识、数据库状态和消息消费状态，再决定是产品缺陷、环境依赖还是测试本身不稳定。

一张决策清单：到底该放哪一层

1. 没有外部系统也能验证吗？能，优先单元测试。
2. 风险集中在 SQL、序列化、事务或协议适配吗？是，增加针对适配器的集成测试。
3. 只有完整链路才能发现问题吗？是，保留少量端到端测试，并覆盖恢复和拒绝路径。
4. 失败后能快速指出责任模块吗？不能，就继续缩小测试范围或补充诊断信息。

最后记住三个边界：单元测试保证规则，集成测试保证连接真实依赖时的契约，端到端测试保证关键业务能走通。三者可以互补，但不应把同一组断言复制三遍。

相关问题

单元测试是否不能使用数据库？

如果目标是验证纯业务规则，最好不要使用数据库；如果目标就是验证仓储与数据库的契约，应把它明确命名为集成测试，而不是靠名称掩盖依赖。

端到端测试越多越可靠吗？

不一定。端到端测试能覆盖真实链路，但执行慢、失败定位难。更稳妥的组合是大量快速单元测试、针对适配器的集成测试，再加少量关键链路端到端测试。