Go中用gomock单元测试sql.DB/Tx调用的难题求助

一、无需包装sql.DB的测试方案 #

方案1：用go-sqlmock直接模拟事务行为 #

不用修改生产代码，直接借助go-sqlmock拦截数据库调用，精准验证Commit()和Rollback()的调用顺序：

• 初始化mock数据库连接：

  db, mock, err := sqlmock.New()
  if err != nil {
      t.Fatalf("初始化mock DB失败: %v", err)
  }
  defer db.Close()
  

• 预设事务调用预期：

  // 预期先执行BeginTx
  mock.ExpectBegin()
  // 根据测试场景设置预期：成功场景用ExpectCommit，失败场景用ExpectRollback
  mock.ExpectCommit()
  // mock.ExpectRollback()
  
  // 将mock DB传入Tx Manager执行业务逻辑
  txMgr := NewTxManager(db)
  err = txMgr.HandleBusiness(ctx)
  

• 验证所有预期是否达成：

  if err := mock.ExpectationsWereMet(); err != nil {
      t.Errorf("未满足预期调用: %v", err)
  }
  

这个库会完全模拟sql.DB和sql.Tx的行为，无需自己做任何包装就能校验调用顺序与次数。

方案2：极简抽象（几乎无侵入生产代码） #

如果不想用第三方库，只需在生产代码中定义两个极小的接口，sql.DB会自动隐式实现：

// 仅定义Tx Manager实际用到的方法，sql.DB天生符合该接口
type DB interface {
    BeginTx(ctx context.Context, opts *sql.TxOptions) (Tx, error)
}

type Tx interface {
    Commit() error
    Rollback() error
}

// Tx Manager依赖DB接口而非具体的sql.DB
type TxManager struct {
    db DB
}

func NewTxManager(db DB) *TxManager {
    return &TxManager{db: db}
}

生产环境直接传入sql.DB即可，测试时编写简单mock：

type mockDB struct{}

func (m *mockDB) BeginTx(_ context.Context, _ *sql.TxOptions) (Tx, error) {
    return &mockTx{}, nil
}

type mockTx struct {
    calls []string
}

func (t *mockTx) Commit() error {
    t.calls = append(t.calls, "commit")
    return nil
}

func (t *mockTx) Rollback() error {
    t.calls = append(t.calls, "rollback")
    return nil
}

// 测试中直接校验调用顺序
func TestTxManager(t *testing.T) {
    mockTx := &mockTx{}
    txMgr := NewTxManager(&mockDB{})
    txMgr.HandleBusiness(ctx)

    if len(mockTx.calls) == 0 || mockTx.calls[0] != "commit" {
        t.Errorf("预期先调用commit，实际调用顺序: %v", mockTx.calls)
    }
}

这种改造是为了代码解耦，并非为测试硬加冗余逻辑，同时完美解决mock问题。

二、为什么Go标准库返回具体类型而非接口？ #

Go的核心设计准则是**"接受接口，返回具体类型"**，原因很直接：

1. 给调用者最大自由度：返回具体类型后，你可以根据自身需求定义抽象接口。比如只需要Commit()和Rollback()就定义极简接口，需要更多方法（如Exec()）再扩展，不会被库的接口限制死。
2. 避免接口冗余：如果标准库返回接口，就得为每个可能的使用场景定义不同接口，反而会导致接口爆炸。返回具体类型能让调用者直接使用所有方法，无需额外类型断言。

虽然这会增加测试mock的成本，但本质是在推动代码解耦——依赖抽象而非具体类型，长远来看能让代码更易维护。

内容的提问来源于stack exchange，提问作者sadensmol