必须先定义接口层才能 mock：rabbitmqconnection 接口含 channel() 和 close() 方法，rabbitmqchannel 接口含 publish() 和 consume() 方法，再用 testify/mock 实现这些接口。
如何用 testify/mock 模拟 amqp.Connection 和 amqp.Channel
Go 的 amqp 包（streadway/amqp）本身不提供接口抽象，直接依赖具体结构体，导致无法直接 mock。必须先提取接口层——这是绕不过去的第一步。
常见错误是试图 mock amqp.Connection 或 amqp.Channel 类型本身，但它们是 struct，Go 不允许对非接口类型打桩。正确做法是定义自己的接口：
type RabbitMQConnection interface {
Channel() (*amqp.Channel, error)
Close() error
}
type RabbitMQChannel interface {
Publish(
exchange, key string,
mandatory, immediate bool,
msg amqp.Publishing,
) error
Consume(queue, consumer string, autoAck, exclusive, noLocal, noWait bool, args amqp.Table) (
<p>然后让真实实现和 mock 实现都满足这些接口。mock 实现中，<code>Publish</code> 可只记录参数，<code>Consume</code> 可返回一个预置的 <code>chan amqp.Delivery</code>，避免启动真实 RabbitMQ。</p>
<h3>如何在测试中触发消息消费逻辑（不依赖真实 Broker）</h3>
<p>单元测试里不该启动真实 RabbitMQ，否则就不是单元测试，而是集成测试。关键在于把“接收消息 → 处理业务逻辑”这一链路拆开，让业务处理函数接收 <code>amqp.Delivery</code> 而非直接依赖 channel。</p>
<p>例如，把消费入口写成：</p>
<pre class="brush:php;toolbar:false;">func HandleDelivery(delivery amqp.Delivery) error {
// 业务逻辑：解析 JSON、更新 DB、发通知等
return processOrder(delivery.Body)
}
这样测试时只需构造一个 amqp.Delivery 实例传入：
delivery := amqp.Delivery{Body: []byte(`{"id":123,"status":"paid"}`)}- 调用
HandleDelivery(delivery) - 断言 DB 状态或返回 error 是否符合预期
不需要任何网络、channel 或 connection，速度快且稳定。
如何验证 Publish 行为是否按预期调用（含 exchange/routing key）
使用 mock 接口后，可记录每次 Publish 的参数，再断言其内容。比如在 mock RabbitMQChannel 中加字段：
type MockChannel struct {
PublishCalls []struct {
Exchange string
Key string
Msg amqp.Publishing
}
}
在 Publish 方法里追加记录：
func (m *MockChannel) Publish(exchange, key string, _, _ bool, msg amqp.Publishing) error {
m.PublishCalls = append(m.PublishCalls, struct{ Exchange, Key string; Msg amqp.Publishing }{
Exchange: exchange,
Key: key,
Msg: msg,
})
return nil
}
测试中调用业务代码后，检查 mockChan.PublishCalls 长度和各字段值即可。特别注意：amqp.Publishing.Body 是 []byte，比较时用 bytes.Equal，别用 ==。
为什么不能直接用 testify/mock 自动生成 amqp.Channel 的 mock
因为 amqp.Channel 是 struct，没有导出的接口定义，mockgen 无法为其生成 mock。强行用 gomock 或 testify/mock 对 struct 打桩会失败，报错类似 cannot generate mock for non-interface type。
更隐蔽的问题是：即使绕过工具限制用反射伪造，也无法覆盖所有方法行为（如 Consume 返回的 channel 是 runtime 创建的，mock 很难模拟其并发语义）。所以必须手动定义接口 + 手写 mock，看似多写几行，实则可控、可读、可维护。
真正容易被忽略的是：很多团队在测试中仍保留 amqp.Dial 调用，只是换成了 localhost:5672 —— 这本质仍是集成测试，CI 环境缺失 RabbitMQ 就会挂，超时风险也高。接口抽象这一步，不是为了“看起来像单元测试”，而是为了把 IO 边界推到最外层，让核心逻辑彻底无依赖。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
