Go Testify 怎样用 InOrder 表达模拟调用先后关系

在 Go 的服务测试里，最容易漏掉的不是“有没有调用”，而是“调用先后是否正确”。例如先准备事务，再写入数据，最后记录审计；如果把审计写在写入之前，单看每个 mock 的调用次数，测试仍可能通过。Testify 的 mock.InOrder 适合表达这类相对顺序。

官方地址：https://pkg.go.dev/github.com/stretchr/testify/mock

先用 On 建立并命名多个 *mock.Call，再把它们按业务语义传给 mock.InOrder；最后仍要调用 AssertExpectations，这样顺序、参数和调用次数才会一起成为测试契约。

先把关键调用拆成可命名的 Call

InOrder 接收的是 *mock.Call，不是方法名字符串。因此不要直接把一串未命名的 On(...) 嵌进去，而是先保存每个关键期望。这样测试失败时能看出是哪一段关系没有满足，也方便给某个调用附加 Once()、Times() 或 Return()。

type StoreMock struct {
	mock.Mock
}

type AuditMock struct {
	mock.Mock
}

func TestProcessOrder(t *testing.T) {
	store := new(StoreMock)
	audit := new(AuditMock)

	// 每个 Call 都对应一个业务节点，参数仍然参与匹配。
	prepare := store.On("Prepare", "order-7").Return(nil).Once()
	save := store.On("Save", "order-7").Return(nil).Once()
	writeAudit := audit.On("Write", "order-7").Return(nil).Once()

	// 先准备，再保存，最后写审计；这里只约束这三个节点的相对顺序。
	mock.InOrder(prepare, save, writeAudit)

	// 被测函数应当在这里执行，例如 service.Process("order-7")。
	service := NewService(store, audit)
	assert.NoError(t, service.Process("order-7"))

	// 断言入口负责汇总顺序、参数和次数等期望。
	store.AssertExpectations(t)
	audit.AssertExpectations(t)
}

这里的重点是把 prepare、save 和 writeAudit 保留下来。它们既是顺序关系的输入，也是普通 mock 断言的输入。Once() 不是 InOrder 的替代品，它只说明同一个期望最多满足一次。

InOrder 约束的是相对先后

官方文档把 InOrder 定义为“定义调用应当发生的顺序”。实践中可以把它理解成一组相邻关系：prepare 必须早于 save，save 必须早于 writeAudit。它并不自动要求这三次调用在整个测试期间连续发生，也不会替你约束没有放进组里的其他 mock 调用。

因此，顺序组应该只覆盖真正有业务含义的节点。比如一个独立的指标计数调用可以留在组外；如果把所有辅助调用都塞进去，测试会从“保护业务协议”变成“绑定实现细节”，后续重构会频繁改测试。

顺序、参数和次数要一起保留

只写 InOrder 不能替代参数匹配。上面的 Save 仍然要求参数是 order-7，Once() 仍然限制调用次数，Return(nil) 则决定被测代码得到的返回值。顺序断言是额外的一层约束，不是把其他约束变弱。

func (m *StoreMock) Save(id string) error {
	// Called 会把真实参数交给 Testify 的期望匹配器。
	args := m.Called(id)
	return args.Error(0)
}

func (m *AuditMock) Write(id string) error {
	// 审计调用也通过同样的入口记录，才能参与顺序断言。
	args := m.Called(id)
	return args.Error(0)
}

// 当顺序错误、参数不符或调用次数不符时，断言阶段都应让测试失败。
func assertAll(t *testing.T, store *StoreMock, audit *AuditMock) {
	store.AssertExpectations(t)
	audit.AssertExpectations(t)
}

如果被测代码先执行了 Write，Testify 会在 mock 调用匹配阶段暴露顺序冲突；如果顺序正确但参数写错，参数匹配仍会失败；如果漏掉某一步，期望断言仍会失败。三类信息要一起看，不能把“测试失败”简单归因于 InOrder 本身。

什么时候不该强行使用 InOrder

如果两个调用天然可以交换，例如分别写两个互不相关的指标，单独用 AssertCalled 或普通期望即可。对并发流程也要谨慎：多个 goroutine 的真实完成顺序可能不稳定，把它们硬编码成线性顺序会让测试变成偶发失败源。此时更适合断言最终状态、每个调用的参数和次数，或只约束确实不可逆的前置关系。

可以把选择标准压缩成一句话：只有当调用顺序本身就是业务协议时，才把它写进 InOrder。如果顺序只是当前实现碰巧如此，就不要让测试替实现做决定。

常见问题

InOrder 是否取代 AssertExpectations？不能。它声明顺序，AssertExpectations 仍负责检查期望是否完成。

只想限制两次调用的顺序怎么办？只把这两个 *mock.Call 传给 mock.InOrder，其余调用保持独立。

顺序正确但测试仍失败怎么办？继续检查 On 的参数、Return 的返回值、Once/Times 的次数，以及是否对每个拥有期望的 mock 调用了断言。

总结：Testify 的 InOrder 最适合表达少量、明确、具有业务含义的相对调用顺序。先保存 *mock.Call，再组合顺序，最后保留参数、次数和断言入口，测试才能既关注协议又不过度绑定实现。