Go Testify 调用参数被原地修改后为什么断言结果异常

Go Testify mock 记录了方法调用，并不意味着它会把所有参数指向的数据自动深拷贝。参数是指针，或包含切片、映射等可变引用时，调用返回后的原地修改可能改变事后断言看到的内容。要检查“调用当时传了什么”，应在调用现场复制需要检查的值，而不是把事后的指针状态当成历史快照。

官方地址：https://github.com/stretchr/testify

Testify 的 mock 文档明确提醒，底层值在调用后变化的指针参数，可能让 AssertCalled 和 AssertNotCalled 产生不符合预期的结果。这个问题来自测试对象的可变性与断言时机，不需要先归因于某个 Go 版本或更换测试框架。

调用记录保存参数，不等于冻结对象

假设报表对象初始状态是 ready。业务调用 Save 时把对象指针传给测试替身，Save 返回后又把同一对象改为 finished。如果 Calls.Arguments 保存的参数仍指向该对象，后面查看记录时看到的就是已经变化的对象。

这会带来两类误解：用新的 ready 对象做 AssertCalled，可能无法匹配已经变化的记录；直接用原指针做断言，又可能因为期待值与记录值一起变化而掩盖差异。因此“地址一样”和“调用当时的内容一样”是两种不同契约。

这不只涉及顶层指针。把结构体复制成值，如果其中仍有切片或映射，底层数据也可能继续共享。排查时要沿着你实际断言的字段检查复制深度，而不是只看方法签名是否使用星号。

先选择你要证明的事情

最重要的是不要用一个事后引用比较同时承担“历史输入”和“最终状态”两项检查。它们发生在不同时间，测试中也应该保留两份含义清楚的数据。

在 Run 中复制需要检查的字段

下面是可以保存为测试文件的原创完整示例，依赖 Testify 的 mock 与 require 包。报表包含字符串、整数切片和字符串映射。Save 的 Run 回调复制这些字段；业务随后修改原对象，最后对快照与最终状态分别做断言。示例没有实际执行，不提供通过截图或测试结果声明。

package reports

import (
    "testing"

    "github.com/stretchr/testify/mock"
    "github.com/stretchr/testify/require"
)

type Report struct {
    Status string
    Rows   []int
    Labels map[string]string
}

type Store interface {
    Save(*Report) error
}

type storeMock struct{ mock.Mock }

func (m *storeMock) Save(r *Report) error {
    return m.Called(r).Error(0)
}

func submit(s Store, r *Report) error {
    if err := s.Save(r); err != nil {
        return err
    }
    // 业务在调用返回后复用并修改同一个对象。
    r.Status = "finished"
    r.Rows[0] = 99
    r.Labels["format"] = "archived"
    return nil
}

func snapshot(r *Report) Report {
    out := Report{Status: r.Status}
    // 保留 nil 与空容器的区别，同时分配独立存储。
    if r.Rows != nil {
        out.Rows = make([]int, len(r.Rows))
        copy(out.Rows, r.Rows)
    }
    if r.Labels != nil {
        out.Labels = make(map[string]string, len(r.Labels))
        for k, v := range r.Labels {
            out.Labels[k] = v
        }
    }
    return out
}

func TestSubmitCapturesSaveInput(t *testing.T) {
    m := new(storeMock)
    var got Report
    captured := false
    m.On("Save", mock.MatchedBy(func(r *Report) bool {
        // 匹配器只判断输入类型及非空，不承担当时值的存储。
        return r != nil
    })).Run(func(args mock.Arguments) {
        got = snapshot(args.Get(0).(*Report))
        captured = true
    }).Return(nil).Once()

    input := &Report{
        Status: "ready",
        Rows: []int{7, 8},
        Labels: map[string]string{"format": "csv"},
    }
    require.NoError(t, submit(m, input))
    require.True(t, captured)
    // 检查独立快照，而不是事后从可变指针重建历史。
    require.Equal(t, Report{
        Status: "ready",
        Rows: []int{7, 8},
        Labels: map[string]string{"format": "csv"},
    }, got)
    require.Equal(t, "finished", input.Status)
    m.AssertExpectations(t)
}

Once 声明预期调用次数，AssertExpectations 用于检查已经声明的预期；got 则专门承载调用现场的业务输入。这两者职责分开，避免把“方法满足预期”误写成“框架已经保存一份不可变历史对象”。

snapshot 为切片和映射分配了新存储，同时保留 nil 与空容器的区别。这里的切片元素是 int、映射值是 string，复制这些值足以覆盖示例中的修改；如果元素改成指针、嵌套映射或带可变字段的结构体，必须继续按业务数据形状复制。它不是通用深拷贝函数。

MatchedBy 不会自动记住第一次匹配的值

MatchedBy 适合判断某次参数是否满足条件，但不是快照容器。不要在匹配器里累加调用次数或写入关键观测状态：匹配行为可能出现在查找预期或事后比较过程中，把副作用放进去会让测试更难解释。

如果只需要证明 Save 接收的 Status 为 ready，可以在注册预期时用纯函数读取字段并返回布尔值；如果还想在调用结束后查看当时的 Rows、Labels，就保留独立快照。本文示例让匹配器只检查非空指针，将观察数据的保存放在 Run 中，便于说明两种职责。

Run 在模拟方法返回之前执行，但也不等于真实方法入口的无限精确时间戳。若同一条调用链有其他回调修改参数，需要明确快照放在这些修改之前还是之后；调用时序由测试替身的设计决定。若要求严格捕获包装方法入口，可以在手写替身方法中先复制，再调用 mock.Called。

不要把串行快照误用到并发测试

示例的 submit 同步调用 Save，Run 完成后才继续修改对象，因此 got 和 captured 的读写在此例中有明确顺序。若被测代码从多个 goroutine 调用 Save，应让快照集合有同步保护，并等待所有调用结束后再读取。

只给快照切片加锁，也不能解决“业务正写入原对象，回调同时复制它”的竞争。需要让对象所有权、调用时机或业务同步先成立。测试框架管理调用记录的锁，不会自动保护你自己的 Report、map 或 slice。

如果为了绕过断言异常直接把期望全部改成 mock.Anything，会失去参数契约检查。只有当测试目标确实不关心参数时，才应采用宽松匹配；否则保留必要字段的纯匹配或快照比较。

为什么换成 AssertNotCalled 也有问题？它同样需要比较调用记录中的参数，官方文档对指针底层值变化也给出了提醒。换成否定断言不会把引用变成历史值。

能否用 JSON 编解码做通用快照？不能不加判断地替代。编码规则会改变可表示字段和类型语义，还可能忽略未导出字段。测试只需哪些业务字段，就为这些字段明确设计复制。

测试只检查调用次数，还需要复制整个对象吗？通常不需要。次数与参数值是不同目标，避免为了一个次数判断引入不必要的对象复制。

参考：AssertCalled 参数可变性说明；Run 回调 API；调用记录实现。