Go sqlmock 数据库模拟测试和真实数据库测试各自能发现什么

数据库测试里最容易混淆的一件事，是把“业务代码按预期调用了 database/sql”和“这条 SQL 在真实数据库里能正确执行”当成同一个问题。Go sqlmock 更适合回答前一个问题：预期的 SQL、参数、事务边界和错误分支是否被正确触发；真实数据库测试则负责回答后一个问题：驱动、SQL 方言、表结构、约束、索引、事务隔离和并发行为是否真的成立。

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

因此，两者不是二选一。sqlmock 是快速、稳定的调用契约测试，真实数据库是环境耦合测试。先把边界分清，失败时才不会把“预期没有被消费”误判成数据库故障。

先把两套测试放进同一张边界表

官方 README 将 sqlmock 定义为实现 database/sql/driver 的 mock 库，目的就是在不建立真实数据库连接的情况下模拟驱动行为。它还明确把“使用真实数据库做功能测试”列为另一种场景。这个划分正好可以作为测试层次的起点。

sqlmock 最擅长检查业务调用契约

假设一个保存订单的方法需要开启事务、执行更新、写入审计记录，第二次操作失败时必须回滚。这里最有价值的断言不是“某台数据库恰好返回了什么”，而是业务代码有没有按约定完成调用链：

package order_test

import (
    "database/sql"
    "testing"

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

func saveOrder(db *sql.DB, orderID int64) error {
    // 生产代码只暴露业务动作，事务结果由 database/sql 返回。
    tx, err := db.Begin()
    if err != nil {
        return err
    }
    if _, err = tx.Exec("UPDATE orders SET status = ? WHERE id = ?", "paid", orderID); err != nil {
        // 发生错误时回滚，避免把半完成事务留给调用方。
        _ = tx.Rollback()
        return err
    }
    if _, err = tx.Exec("INSERT INTO order_audits(order_id, action) VALUES (?, ?)", orderID, "paid"); err != nil {
        // 审计写入失败也必须回滚前面的订单更新。
        _ = tx.Rollback()
        return err
    }
    return tx.Commit()
}

func TestSaveOrderRollsBackWhenAuditFails(t *testing.T) {
    db, mock, err := sqlmock.New()
    if err != nil {
        t.Fatalf("创建 mock 数据库失败: %v", err)
    }
    defer db.Close()

    // 预期顺序表达业务契约，而不是验证真实表是否存在。
    mock.ExpectBegin()
    mock.ExpectExec("UPDATE orders").WithArgs("paid", int64(9)).
        WillReturnResult(sqlmock.NewResult(0, 1))
    mock.ExpectExec("INSERT INTO order_audits").WithArgs(int64(9), "paid").
        WillReturnError(assertionError("审计写入失败"))
    mock.ExpectRollback()

    if err := saveOrder(db, 9); err == nil {
        t.Fatal("预期审计失败，但业务函数返回了 nil")
    }
    // 这个出口确认每个预期调用都已被消费。
    if err := mock.ExpectationsWereMet(); err != nil {
        t.Fatalf("调用契约未满足: %v", err)
    }
}

type assertionError string

func (e assertionError) Error() string { return string(e) }

这类测试可以很快发现 SQL 调用缺失、参数顺序颠倒、错误分支没有回滚、应该提交却调用了回滚等问题。sqlmock 还支持默认的严格预期顺序，以及对参数和返回行的精确设置，所以它适合覆盖很多细小分支。

但它不会替你创建 orders 表，也不会证明数据库真的接受这条 SQL。即使预期字符串写得完全正确，真实环境中的字段类型、关键字、方言差异仍可能让集成测试失败。

真实数据库测试要确认运行时事实

当风险来自数据库本身时，必须让代码连接到与生产尽量接近的数据库。下面这些问题不应由 sqlmock 单独承担：

• 模式与约束：列类型、非空约束、唯一约束、外键和默认值是否与代码假设一致。
• 方言与驱动：占位符、返回值、日期函数、批量语句和驱动转换是否真的可用。
• 查询计划：索引是否被使用，排序、连接和大数据量扫描是否出现明显退化。
• 事务环境：提交、回滚、锁等待、隔离级别和并发写入是否符合业务要求。

例如，sqlmock 可以让 UPDATE ... WHERE id = ? 按预期返回一行受影响记录，但真实数据库可能因为字段类型转换、触发器或约束而返回不同结果。这个差异不是 mock 写错了，而是两种测试关注的对象不同。

真实数据库测试还应该使用独立的测试数据和可重复的初始化方式，测试结束后清理数据或销毁临时数据库。不要把开发者本机某个长期运行的数据库当成稳定的集成环境，否则失败结果会夹杂旧数据和手工配置。

按风险把两类测试组合起来

一套实用的迁移清单可以这样安排：

1. 先用 sqlmock 覆盖分支：把成功、参数错误、事务开始失败、SQL 执行失败、提交失败和回滚路径固定下来。
2. 再用真实数据库覆盖环境：确认迁移后的表结构、约束、索引、方言和驱动行为与代码一致。
3. 对关键查询做双重检查：模拟测试关注调用契约，真实测试关注真实返回值、行数和错误类型。
4. 发布前加入并发与数据量场景：只有这一步才能较早发现锁、隔离级别、超时和查询计划方面的问题。

如果一条查询经常因为格式化或不同驱动而变化，sqlmock 的预期不要写得比业务意图更脆弱；可以选择合适的 QueryMatcher，或者只断言关键调用契约。反过来，涉及数据库特有语法时，不要因为模拟测试通过就跳过真实数据库回归。

常见问题

sqlmock 测试通过，为什么上线后仍然报 SQL 错误？

因为 sqlmock 只模拟驱动行为，不会检查真实表结构、数据库方言、权限、约束和索引。涉及这些因素的代码必须补真实数据库测试。

真实数据库测试通过后，还需要 sqlmock 吗？

需要。真实测试能证明某些环境事实，但不一定覆盖每个错误分支和事务调用顺序；sqlmock 能以更低成本把这些业务契约固定下来。

是不是所有数据库代码都要写两套完全相同的测试？

不必机械复制。把分支、参数和事务契约放在 sqlmock，把方言、模式、约束、查询计划和并发风险放在真实数据库，测试内容应按风险拆开。