Go sqlmock 怎么为动态时间参数定义匹配器

在 sqlmock 中，动态时间参数不要用测试开始时保存的另一个 time.Now() 去做精确比较。业务代码和测试代码得到的时间几乎必然不同，断言会把正常调用误判成参数不匹配。更稳妥的做法是实现 sqlmock.Argument，在 Match(driver.Value) 中确认它经过 database/sql 驱动层后仍是 time.Time，再把这个匹配器放进 WithArgs。

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

规模背景：精确时间断言为什么撑不住

一条写入用户的 SQL 往往同时包含固定的用户名和动态的 created_at。如果把两个参数都当成普通值，测试就必须预先猜中业务函数稍后生成的纳秒级时间；这会让测试在机器负载、调用顺序或时区处理变化时变得脆弱。

真正需要保持精确的是 SQL、用户名等固定事实，动态时间只需要验证它属于允许的参数类型，或者落在业务允许的时间窗口内。sqlmock 的 Argument 接口正好把这两个断言边界拆开。

原架构瓶颈：不要把两个 time.Now 直接比较

下面这种写法把测试中的时间值和生产代码中的时间值绑定在一起，几乎没有稳定的匹配机会：

// 反例：两次调用 time.Now 得到的值通常不同，精确比较很脆弱
expectedAt := time.Now()
mock.ExpectExec("INSERT INTO users").
    WithArgs("alice", expectedAt).
    WillReturnResult(sqlmock.NewResult(1, 1))

// 被测函数内部又生成了另一个当前时间
_, err := db.Exec("INSERT INTO users(name, created_at) VALUES (?, ?)",
    "alice", time.Now())
if err != nil {
    t.Fatal(err)
}

问题不在 SQL，而在断言把“时间字段存在且类型正确”误写成了“必须等于某个提前生成的瞬间”。规模化测试中，这类偶然失败会掩盖真正的数据库交互问题。

新架构：用 Argument 把动态参数隔离出来

sqlmock 的 Argument 只要求一个 Match(driver.Value) bool 方法。下面的匹配器只接受 time.Time，不会放宽用户名和 SQL 的断言：

package user_test

import (
    "database/sql/driver"
    "testing"
    "time"

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

// AnyTime 只放宽动态时间字段，其他参数仍由 WithArgs 精确匹配。
type AnyTime struct{}

// Match 接收 database/sql 传给驱动层的参数值。
func (AnyTime) Match(v driver.Value) bool {
    _, ok := v.(time.Time)
    return ok
}

func TestCreateUser(t *testing.T) {
    db, mock, err := sqlmock.New()
    if err != nil {
        t.Fatal(err)
    }
    defer db.Close() // 测试结束关闭连接，避免资源泄漏

    mock.ExpectExec("INSERT INTO users").
        WithArgs("alice", AnyTime{}).
        WillReturnResult(sqlmock.NewResult(1, 1))

    // 被测调用里的时间可以每次不同，匹配器只检查其类型。
    _, err = db.Exec("INSERT INTO users(name, created_at) VALUES (?, ?)",
        "alice", time.Now())
    if err != nil {
        t.Fatal(err)
    }

    // 保留期望检查，避免只验证 Exec 没有验证参数是否真的匹配。
    if err := mock.ExpectationsWereMet(); err != nil {
        t.Fatal(err)
    }
}

这里的静态关系很清楚："alice" 仍然是固定断言，AnyTime{} 只占据动态时间参数的位置。driver.Value 是匹配器的输入边界，因此不要在 Match 中假设能拿到业务结构体指针或完整请求对象。

关键取舍：类型匹配还是时间窗口匹配

AnyTime 的优点是简单、稳定，适合只关心字段是否被正确传入的测试；代价是它不会判断时间是否过早、过晚或属于某个业务批次。如果时间新鲜度本身就是业务规则，可以把规则写进同一个匹配器，例如先断言 time.Time，再用固定的 min、max 做窗口判断。窗口值应来自测试夹具，而不是在 Match 中再次调用 time.Now()，否则断言仍会漂移。

不要用 sqlmock.AnyArg() 替代所有动态参数：它会接受任意类型，可能让时间字段被错误的字符串或整数悄悄通过。匹配器越贴近参数的真实约束，测试对回归越有辨识力。

上线结果：让失败信息回到真正的边界

采用自定义匹配器后，时间精度不再成为偶然失败源，固定参数和 SQL 仍能在期望检查中暴露错误。建议把匹配器命名为 AnyTime、TimeBetween 这类能表达约束的类型，并在项目测试包中复用；当业务从“只要是时间”升级为“必须在请求开始后十秒内”，只调整时间匹配器，不改所有 SQL 期望。

常见问题

为什么 Match 的参数是 driver.Value？ 因为 sqlmock 在参数进入驱动层的边界上进行匹配，匹配器应针对驱动可接收的值做判断。

只需要判断任意参数时怎么办？ 可以使用 sqlmock 内置的 AnyArg()，但动态时间通常更适合保留 time.Time 类型约束。