Go语言如何编写一次接口测试用例适配所有实现运行？

你提到的两种方案确实各有弊端，目前Go生态中最常用的是通用测试辅助函数方案，简洁性、解耦性都更优：

方案实现步骤 #

1. 接口定义侧编写通用测试函数 #

在接口所在的包中新建*_test.go或者*_test_helpers.go文件，编写纯测试函数，直接接收接口实例和*testing.T作为参数：

// users包下的 repo_test_helper.go
package users

import "testing"

// TestUserRepository_StoreUser 是所有UserRepository实现都需要通过的通用测试
func TestUserRepository_StoreUser(t *testing.T, repo UserRepository) {
    // 所有通用测试逻辑写在这里，支持表驱动测试用例
    testCases := []struct {
        name    string
        input   User
        wantErr bool
    }{
        {
            name: "正常保存新用户",
            input: User{ID: 1, Name: "张三"},
            wantErr: false,
        },
        {
            name: "重复ID保存返回错误",
            input: User{ID: 1, Name: "张三"},
            wantErr: true,
        },
    }

    for _, tc := range testCases {
        t.Run(tc.name, func(t *testing.T) {
            res, err := repo.StoreUser(tc.input)
            if tc.wantErr {
                if err == nil {
                    t.Fatal("期望返回错误，实际未返回")
                }
                return
            }
            if err != nil {
                t.Fatalf("期望无错误，实际返回错误：%v", err)
            }
            if res.ID != tc.input.ID || res.Name != tc.input.Name {
                t.Fatalf("返回用户不匹配，期望：%+v，实际：%+v", tc.input, res)
            }
        })
    }
}

2. 各实现侧直接调用通用测试 #

每个实现只需要在自己包的测试文件中，完成自身实例的初始化后，调用上述通用测试函数即可：

内存实现的测试：

// inmemory包下的 user_repo_test.go
package inmemory

import (
    "testing"
    "your_module_path/users"
)

func TestInMemoryRepository_StoreUser(t *testing.T) {
    // 初始化内存实现实例
    repo := NewInMemoryRepository()
    // 调用通用测试
    users.TestUserRepository_StoreUser(t, repo)
    
    // 如有内存实现特有的测试逻辑可以单独写在这里
}

Postgresql实现的测试：

// postgres包下的 user_repo_test.go
package postgres

import (
    "testing"
    "your_module_path/users"
)

func TestPostgresqlRepository_StoreUser(t *testing.T) {
    // 处理pg特有初始化逻辑：比如启动测试数据库、建表、预处理数据
    repo := NewPostgresqlRepository(t)
    // 调用通用测试
    users.TestUserRepository_StoreUser(t, repo)
    
    // 如有pg实现特有的测试逻辑可以单独写在这里
}

方案优势 #

• 完全解耦：接口定义侧不需要感知任何实现，新增实现时不需要修改接口侧代码，符合开闭原则
• 无冗余封装：相比方案b不需要额外定义测试结构体，纯函数调用成本极低
• 灵活性高：每个实现可以自行处理初始化、资源清理逻辑，比如PG需要启动测试容器、内存实现不需要的差异完全由各实现自己控制
• 测试粒度可控：可以单独运行某一个实现的测试，不需要全量跑所有实现的测试
• 扩展性好：接口新增方法时，只需要在接口侧新增对应的通用测试函数，所有实现自动可以复用

原方案的不足对比 #

• 方案a：所有实现的初始化逻辑都需要耦合在接口侧的测试代码中，会导致接口包依赖所有实现的依赖，新增实现必须修改接口侧测试代码，不符合开闭原则
• 方案b：多了一层不必要的测试结构体封装，纯函数即可实现的能力额外增加了复杂度

内容的提问来源于stack exchange，提问作者GioGio