Go sqlmock 怎么测试写入失败后的事务回滚

Go 里测试“第二次写入失败后必须回滚”，关键不是只断言函数返回了 error，而是把事务边界也写成可消费的预期：ExpectBegin、第一次成功的 ExpectExec、第二次带错误的 ExpectExec，最后是 ExpectRollback。这样测试才能证明失败分支没有误走 Commit。

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

先让错误决定事务结局

下面的函数模拟保存订单：先写订单，再写审计记录。第二次写入失败时，命名返回值 err 会让延迟函数进入回滚分支。成功路径才提交，这个结构也是测试能准确验证回滚的前提。

package order

import "database/sql"

func SaveOrder(db *sql.DB, orderID, operatorID int64) (err error) {
	// 事务只在本函数创建，退出时统一决定提交还是回滚。
	tx, err := db.Begin()
	if err != nil {
		return err
	}
	defer func() {
		if err != nil {
			// 任一步写入失败都回滚，避免留下半条订单。
			_ = tx.Rollback()
			return
		}
		err = tx.Commit()
	}()

	if _, err = tx.Exec("INSERT INTO orders(id, operator_id) VALUES (?, ?)", orderID, operatorID); err != nil {
		return err
	}
	if _, err = tx.Exec("INSERT INTO order_audits(order_id) VALUES (?)", orderID); err != nil {
		return err
	}
	return nil
}

这里的 Rollback 错误被有意忽略，因为原始写入错误才是调用方需要处理的原因。若项目把回滚失败也纳入审计，可以另记日志，但不要覆盖原错误。

用预期链锁定失败写入

测试先声明成功的 Begin 和订单插入，再让审计插入返回一个明确错误，最后声明 Rollback。sqlmock 默认按顺序匹配预期；SQL 中的括号、问号等字符可能参与正则匹配，因此示例用 regexp.QuoteMeta 把完整语句转为字面量。

package order_test

import (
	"errors"
	"regexp"
	"testing"

	"github.com/DATA-DOG/go-sqlmock"
	"example.com/order"
)

func TestSaveOrderRollbackWhenAuditWriteFails(t *testing.T) {
	// 创建只用于测试的驱动连接，不连接真实数据库。
	db, mock, err := sqlmock.New()
	if err != nil {
		t.Fatalf("创建 sqlmock 连接失败: %v", err)
	}
	defer db.Close()

	insertOrder := regexp.QuoteMeta("INSERT INTO orders(id, operator_id) VALUES (?, ?)")
	insertAudit := regexp.QuoteMeta("INSERT INTO order_audits(order_id) VALUES (?)")
	mock.ExpectBegin()
	mock.ExpectExec(insertOrder).
		WithArgs(int64(7), int64(42)).
		WillReturnResult(sqlmock.NewResult(7, 1))
	mock.ExpectExec(insertAudit).
		WithArgs(int64(7)).
		WillReturnError(errors.New("audit write failed"))
	mock.ExpectRollback()

	// 业务函数应返回第二次写入的错误，而不是伪造成功。
	err = order.SaveOrder(db, 7, 42)
	if err == nil || err.Error() != "audit write failed" {
		t.Fatalf("期望保留写入错误，实际得到: %v", err)
	}
	// 这个检查会发现漏掉 Rollback、顺序错乱或参数不匹配。
	if err := mock.ExpectationsWereMet(); err != nil {
		t.Fatalf("事务预期未完成: %v", err)
	}
}

参数、风险与验证清单

如果业务代码在失败后没有返回错误，defer 就可能提交；如果测试把 ExpectCommit 写在失败预期后，顺序错误会直接暴露。为了覆盖完整边界，再单独写一个成功用例验证 Commit，不要让回滚用例承担两条路径。

延伸问答

为什么只检查业务返回 error 还不够？

因为返回错误不能证明事务已经回滚。漏写 Rollback、误调用 Commit，甚至没有真正执行第二次写入，都可能被单一错误断言掩盖。

ExpectationsWereMet 应该放在哪里？

放在业务函数调用之后，并在业务结果断言之后或紧邻其后执行。它负责核对预期调用是否全部按顺序发生。

SQL 很复杂时怎样减少匹配脆弱性？

固定 SQL 可用 regexp.QuoteMeta；若需要大小写和空白都严格一致，可选择 sqlmock 的等值匹配器，同时保持参数单独用 WithArgs 验证。