Go sqlmock 并发查询测试为什么受到预期顺序影响

我第一次把一组数据库读取改成并发后，sqlmock 报出的错误很容易让人误以为 SQL 写错了：明明每条预期都已经注册，错误却说“下一条预期”没有匹配。真正的问题通常是默认的顺序约束仍然存在，而 goroutine 到达 mock 的先后并不由预期注册顺序决定。

官方地址：https://github.com/DATA-DOG/go-sqlmock

如果多个 goroutine 执行的是互相独立的查询，应在注册完预期后调用 mock.MatchExpectationsInOrder(false)。它只放宽预期的匹配顺序，SQL 表达式、参数和最终的未完成预期检查仍然保留；事务等有因果关系的操作不要照搬这个设置。

先把报错拆成顺序问题还是匹配问题

sqlmock 默认按预期加入队列的顺序匹配。假设先注册了查询 A，再注册查询 B，但 goroutine B 先调用 db.Query，严格顺序模式就可能先拿查询 A 对照，随后返回“当前调用不是预期的下一项”。这和 SQL 正则、参数值不匹配是两类问题。

排查时先看错误中是否出现“next expectation”或“下一条预期”，再确认并发调用是否真的没有业务先后关系。如果同一个事务必须先 Begin、再写入、再 Commit，就不能用放宽顺序来掩盖调用链错误。

最小修复：注册预期后关闭并发顺序匹配

官方接口把这个开关设计在 mock 上。位置要放在预期注册完成后、并发查询开始前，读者一眼就能看出这组预期允许乱序匹配。

func TestLoadWidgetsConcurrently(t *testing.T) {
	// 创建不会连接真实数据库的 mock DB，并由 mock 管理预期。
	db, mock, err := sqlmock.New()
	if err != nil {
		t.Fatalf("创建 sqlmock 失败: %v", err)
	}
	defer db.Close()

	// 先声明所有独立查询，再关闭“按注册顺序匹配”的约束。
	mock.ExpectQuery(`SELECT id, name FROM widgets WHERE owner_id = \?`).
		WithArgs(10).
		WillReturnRows(sqlmock.NewRows([]string{"id", "name"}).AddRow(1, "alpha"))
	mock.ExpectQuery(`SELECT id, name FROM widgets WHERE owner_id = \?`).
		WithArgs(20).
		WillReturnRows(sqlmock.NewRows([]string{"id", "name"}).AddRow(2, "beta"))
	mock.MatchExpectationsInOrder(false)

	var wg sync.WaitGroup
	for _, ownerID := range []int{10, 20} {
		id := ownerID
		wg.Add(1)
		go func() {
			defer wg.Done() // 每个 goroutine 都必须通知等待方收敛。
			rows, queryErr := db.Query("SELECT id, name FROM widgets WHERE owner_id = ?", id)
			if queryErr != nil {
				t.Errorf("查询 owner_id=%d 失败: %v", id, queryErr)
				return
			}
			defer rows.Close() // 读取完成后释放 rows，避免留下未关闭结果集。
		}
	}
	wg.Wait()

	// 乱序只影响匹配入口，所有预期仍需在这里收敛。
	if err := mock.ExpectationsWereMet(); err != nil {
		t.Fatalf("仍有未满足预期: %v", err)
	}
}

示例中两条预期通过 WithArgs 区分 owner_id，所以 false 不是“什么 SQL 都算通过”。它只是让 sqlmock 在未完成预期中寻找能匹配当前 SQL 与参数的那一条。

为什么 false 仍然不会放弃 SQL 和参数检查

这个开关经常被误解成“关闭了断言”。实际需要保留三层边界：调用方传入的 SQL 仍要经过查询匹配器，WithArgs 仍要比较参数，所有 goroutine 结束后 ExpectationsWereMet 仍会报告没有被触发的预期。

因此并发测试的稳定写法是：把每个独立查询的差异写进预期，把 WaitGroup 只用来等待调用完成，不用它制造固定的执行顺序。若两条预期的 SQL 和参数完全相同，则还需要让返回结果或测试数据具备可区分性，否则测试本身无法说明某个 goroutine 得到了哪份业务结果。

哪些场景不能直接关掉顺序

我更愿意把这个设置看成“缩小断言范围”，而不是并发测试的默认开关。下面几类调用仍然应保持顺序，或者拆成更清晰的测试边界：

• 事务操作：ExpectBegin、写入、ExpectCommit 或 ExpectRollback 有明确因果关系。
• 依赖前一步结果的查询：第二次查询使用第一次返回的 ID，乱序会改变业务语义。
• 同一资源的状态转换：测试的重点就是“先更新再读取”时，顺序本身属于被测行为。

func TestUpdateThenRead(t *testing.T) {
	// 这里的先后是业务契约，不应为了消除并发报错而关闭顺序匹配。
	db, mock, err := sqlmock.New()
	if err != nil {
		t.Fatalf("创建 sqlmock 失败: %v", err)
	}
	defer db.Close()

	mock.ExpectBegin()
	mock.ExpectExec(`UPDATE widgets SET name = \? WHERE id = \?`).
		WithArgs("renamed", 7).
		WillReturnResult(sqlmock.NewResult(0, 1))
	mock.ExpectCommit()

	// 只有独立查询才适合 MatchExpectationsInOrder(false)。
	if _, err := db.Exec("UPDATE widgets SET name = ? WHERE id = ?", "renamed", 7); err != nil {
		t.Fatalf("更新失败: %v", err)
	}
	if err := mock.ExpectationsWereMet(); err != nil {
		t.Fatalf("事务预期未满足: %v", err)
	}
}

并发查询测试的速查表

相关问题

MatchExpectationsInOrder(false) 会不会掩盖 SQL 错误？

不会自动掩盖。当前 SQL 仍需匹配某条未完成预期，参数也会继续比较；真正需要注意的是不要把多条预期写成完全相同却无法区分的规则。

为什么 WaitGroup 不能代替 sqlmock 的顺序设置？

WaitGroup 只负责等待 goroutine 完成，不规定它们访问 mock 的先后。它解决生命周期收敛，MatchExpectationsInOrder 解决预期如何匹配，两者职责不同。