本文介绍一种面向业务契约而非底层 sdk 接口的测试策略，通过定义领域专属接口（如 userstore）替代直接 mock 第三方客户端，显著提升可测性、解耦度与维护性。
本文介绍一种面向业务契约而非底层 sdk 接口的测试策略，通过定义领域专属接口（如 userstore）替代直接 mock 第三方客户端，显著提升可测性、解耦度与维护性。
在 Go 的 TDD 实践中，许多开发者初学时会陷入一个常见误区：试图对第三方库（如 github.com/go-redis/redis）的客户端方法逐层抽象、封装、mock——例如为 Client.Get、Client.TxPipeline 甚至其返回的 redis.Pipeliner 接口都定义对应 wrapper。这种“镜像式接口”不仅代码冗余、维护成本高，更违背了依赖倒置原则：你的业务逻辑本不该感知 Redis 的 API 细节，而应关注“我需要什么能力”。
✅ 正确做法是：自顶向下设计，按业务语义定义接口。
假设你的服务需要“存储用户”和“按 ID 查询用户”，那就定义清晰、窄契约的领域接口：
type UserStore interface {
SaveUser(*User) error
GetUserByID(string) (*User, error)
SearchUsers(string) ([]User, error)
}
该接口完全脱离 Redis、PostgreSQL 或任何具体实现，只表达业务意图。接着编写真实实现：
type RedisUserStore struct {
client *redis.Client
}
func (s *RedisUserStore) SaveUser(u *User) error {
data, err := json.Marshal(u)
if err != nil {
return fmt.Errorf("marshal user: %w", err)
}
return s.client.Set(fmt.Sprintf("user:%s", u.ID), data, 0).Err()
}
func (s *RedisUserStore) GetUserByID(id string) (*User, error) {
val, err := s.client.Get(fmt.Sprintf("user:%s", id)).Result()
if err == redis.Nil {
return nil, ErrUserNotFound
}
if err != nil {
return nil, fmt.Errorf("redis get: %w", err)
}
var u User
if err := json.Unmarshal([]byte(val), &u); err != nil {
return nil, fmt.Errorf("unmarshal user: %w", err)
}
return &u, nil
}
此时，测试不再关心 TxPipeline 返回了什么接口，也不用模拟整个 Redis 命令集——你只需 mock UserStore 这 3 个方法即可。更灵活的是，你可以使用函数字段型 mock（functional mock），避免为每个测试场景新建结构体：
type MockUserStore struct {
SaveUserFunc func(*User) error
GetUserByIDFunc func(string) (*User, error)
}
func (m *MockUserStore) SaveUser(u *User) error {
if m.SaveUserFunc != nil {
return m.SaveUserFunc(u)
}
return nil
}
func (m *MockUserStore) GetUserByID(id string) (*User, error) {
if m.GetUserByIDFunc != nil {
return m.GetUserByIDFunc(id)
}
return nil, nil
}
在测试中轻松构造各类场景：
func TestUserService_CreateUser_WhenDuplicateIDReturnsError(t *testing.T) {
mockStore := &MockUserStore{
SaveUserFunc: func(u *User) error {
if u.ID == "existing" {
return errors.New("duplicate key")
}
return nil
},
}
svc := NewUserService(mockStore)
err := svc.CreateUser(&User{ID: "existing"})
assert.Error(t, err)
}
⚠️ 注意事项：
-
永远不要暴露第三方类型到你的公共接口（如
redis.Client、*sql.DB），否则你的业务层将被绑定到特定实现； - 若需事务支持（如 Redis MULTI），应在
UserStore接口中显式定义事务语义（如InTransaction(func(UserStore) error) error），而非暴露TxPipeline； - 对于集成测试，建议使用 testcontainers-go 启动真实 Redis 实例，验证端到端行为；单元测试则专注逻辑与错误分支覆盖。
总结：Go 的接口轻量特性不是为了“复制粘贴 SDK 接口”，而是为了描述能力契约。聚焦“我要做什么”，而非“第三方让我怎么做”——这才是可测试、可替换、可持续演进的 Go 架构核心。
