Golang 项目单测经验杂谈

本文结合实际项目经验，分享 Golang 单元测试实践，涵盖 mockery、gomonkey 使用方式、常见误区及 AI 写单测的优缺点

写单测的出发点：质量保障与过程指标

在实际项目中，单元测试的主要出发点是保障代码改动不引入潜在 Bug。代码每一次修改都可能影响原有逻辑，良好的单测可以在开发阶段就捕获问题，避免 Bug 流入生产环境。业界常用 “千行代码Bug率” 来衡量代码质量，即每千行代码包含的缺陷数量，计算公式：bug数/代码行数*1000。这个指标表明：代码量越大，若无相应测试保障，潜在缺陷可能越多。通过单元测试及代码评审等手段，团队可以将缺陷密度降至合理范围，从而提高代码可靠性。

另一个重要指标是代码覆盖率，尤其是增量覆盖率。覆盖率反映测试代码触及了业务代码的程度，很多团队强制新提交代码的覆盖率不低于某个阈值，例如 80%。增量覆盖率指针对每次增量改动所新增代码的覆盖率，这保证了每次功能迭代都配套相应的测试用例。把单测作为质量基线，可以有效降低「千行代码 Bug 率」，减少因为改动引入 Bug 的风险。

值得一提的是，单元测试还能提供快速反馈机制。当我们对已有模块做重构或功能升级时，跑一遍单测就能迅速验证改动是否影响原有功能。这种增量验证让开发者对自己的修改更有信心。总的来说，单测的目标不止是数字上的覆盖率，更是构筑修改代码的安全网。当覆盖率达到一定水平，未覆盖代码往往意味着潜在风险点。因此，写单测已成为提升代码质量和维护效率的必要实践。

单元测试粒度：外层黑盒 vs 内层白盒

在设计单元测试时，需要合理控制测试的粒度。一般有两种思路：

• 外层黑盒测试：从模块对外暴露的接口出发进行测试，不关心内部实现细节。我们把被测代码当作黑盒，根据输入推断输出，验证功能是否符合预期。这类似于模拟真实调用场景，优点是稳定性高、更贴近业务使用。例如测试一个 API 时，只关注其返回结果和副作用，而不深入其内部过程。黑盒测试能在接口契约不变的情况下容忍内部重构，测试用例不需要修改。
• 内层白盒测试：对模块内部的函数和逻辑进行细粒度测试，了解代码内部如何处理输入。白盒测试关注程序的执行路径、分支覆盖，对于复杂算法或关键函数可以逐一验证边界条件和内部状态。其优点是定位问题精确，覆盖更全面。例如一个复杂的计算函数，可以直接调用内部函数来测试各种极端参数的处理。白盒测试往往需要将测试代码放在与被测代码相同的包下，以访问非导出函数或状态。

两种粒度各有适用场景。在实际经验中，倾向首先编写黑盒测试验证模块的对外行为是否正确，再针对难以覆盖到的内部逻辑补充白盒测试作为辅助手段。

举个例子，如果一个服务调用了多个依赖服务并进行复杂处理，黑盒测试可以模拟依赖的正常返回，验证整体输出；而对于某些内部的计算边界（比如日期处理、随机数逻辑），我们可能写白盒测试直接调用内部函数进行验证。

需要注意的是，过度细碎的白盒测试可能会与实现细节强耦合，导致一旦重构实现，测试也要跟着改动。我的经验是：保证核心业务路径用黑盒测试覆盖，关键算法和极端情况用白盒测试兜底，两者结合既保证了对外行为稳定，又兼顾了内部复杂逻辑的正确性。

使用 Mockery 模拟接口依赖

在 Go 语言中，鼓励通过接口来解耦组件依赖。在单元测试中，如果被测函数依赖某个接口（例如数据库或外部服务接口），可以使用 Mockery 工具生成该接口的模拟实现，从而隔离外部依赖。Mockery 是一个流行的 Go Mock 生成器，它自动为接口生成带有期望设定功能的结构体，实现接口的所有方法 。使用 Mockery 的基本步骤如下：

1.安装 Mockery 工具

在 Go1.16+ 环境下通过 go install 安装。例如安装最新版本：

go install github.com/vektra/mockery/v2@latest

安装后会在 $GOPATH/bin 下生成 mockery 可执行文件

2.生成接口的 Mock 实现

假设我们有一个接口定义如下：

// internal/metrics/getter.go
package metrics
type Getter[T any] interface {
    Get() (T, error)
}

可以在项目根目录运行 Mockery 命令生成模拟类：

mockery --name=Getter --dir=internal/metrics --output=mocks 

以上命令指定接口名称为 Getter，并指明接口所在目录，生成的模拟实现将输出到 mocks 目录下（默认文件名为 metrics_mock.go 等）。生成的 Mock 类通常会嵌入 testify/mock 提供的 Mock 基类，便于设定期望行为和断言调用。

3.在测试中使用 Mock

在单测中，引入生成的模拟类包，创建模拟对象并设置其方法返回值。例如，对于上述 Getter 接口，生成的模拟类型假设名为 mocks.Getter：

import (
    "testing"
    "github.com/stretchr/testify/assert"
    "project/mocks"  // 引入生成的mock包
)
func TestdoSomething(t *testing.T) {
    // 假设被测函数doSomething依赖 Getter[int] 接口
    m := new(mocks.Getter[int])
    m.On("Get").Return(123, nil)  // 设置当调用Get方法时返回123,nil
    result := doSomething(m)      // 调用被测函数，传入mock对象
    assert.Equal(t, 123, result)
    m.AssertExpectations(t)       // 验证所有预期的调用都发生了
}

上述示例中，我们通过 m.On("Get") 方法定义了接口方法的模拟行为：无论参数如何，调用时都返回预设值 123 和 nil 错误 。然后将这个 m 传入被测函数，断言返回结果是否符合预期，并调用 AssertExpectations 确认模拟对象的所有预期交互都已发生。

使用 Mockery 的注意事项：

• 接口必须设计良好：Mockery 只能为接口生成 mock，因此确保我们的代码针对依赖使用了接口抽象（面向接口编程）。如果依赖是硬编码的具体类型或全局函数，需考虑重构以支持注入，或使用下面介绍的 Gomonkey 打桩方案。
• Mock 文件管理：建议将生成的 mock 文件隔离在独立的包（如 mocks）中，避免命名冲突和循环依赖。生成后应将代码纳入版本管理，方便团队共享。如果接口修改，记得重新运行 mockery 生成更新的模拟代码。
• 配置与命名：Mockery 提供了丰富的 CLI 选项，例如使用 --all 一键为整个项目所有接口生成 mocks，或通过 --recursive 递归扫描子目录 。也可以通过在项目根目录添加 .mockery.yaml 文件来配置默认参数，如输出路径、命名风格等。
• 合理使用断言：testify 的 mock 可以记录接口调用情况，如参数是否符合预期、调用次数等 。编写单测时应充分利用这些断言能力，确保被测代码按期望调用了依赖接口的方法。例如可以使用 Once() 限制期望某方法只应被调用一次，AssertNumberOfCalls 检查调用次数等 。这些都有助于提升测试的准确性，避免漏掉关键交互验证。

总之，Mockery 极大降低了编写 mock 类的工作量。通过它生成的模拟对象，我们能精确控制依赖行为，使单元测试聚焦于当前模块的逻辑。本质上，这是利用 “替身”（Stub/Mock） 实现依赖隔离的典型做法：将原本依赖的真实逻辑替换为可控的假对象，从而只测试我们关心的部分。

使用 Gomonkey 打桩不可控函数

除了依赖接口之外，有些代码依赖全局函数或不可直接替换的函数（如来自标准库或第三方包的静态方法）。对于这类依赖，Mockery 无能为力，因为它们不是接口。这时可以使用 Gomonkey 提供的补丁（Monkey Patch）功能，对特定函数进程打桩（Stub）替换。在 Golang 单测中，Gomonkey 常被用于替换诸如 time.Now()、math/rand.Int() 这类不易控制的函数输出 。
基本用法：Gomonkey 提供了多个打桩方法，其中最常用的是 ApplyFunc，用于替换包级别函数的实现 。调用 gomonkey.ApplyFunc(targetFunc, stubFunc) 会在运行时将 targetFunc 的入口指向我们提供的 stubFunc，从而每次调用都会执行桩函数的逻辑 。例如，我们希望在测试中固定 time.Now() 返回的时间，可以这样写：

import (
    "time"
    "github.com/agiledragon/gomonkey/v2"
)
func TestSomethingTime(t *testing.T) {
    fixed := time.Date(2025, 1, 1, 0, 0, 0, 0, time.UTC) 
    patches := gomonkey.ApplyFunc(time.Now, func() time.Time {
        return fixed  // stub函数始终返回预设时间
    })
    defer patches.Reset()  // 确保测试结束时恢复原状 

    // ... 此处调用包含 time.Now() 的被测函数 ...
}

如上，我们用 ApplyFunc 将 time.Now 替换成了返回固定时间 fixed 的函数 。这样一来，被测代码中无论调用多少次 time.Now()，得到的都是可预测的 2025-01-01 时刻。通过这种手段，我们消除了时间依赖带来的不确定性，使测试结果可重复。测试完成后通过 defer patches.Reset()来恢复原函数，实现对全局状态的清理。

常见的打桩场景还包括：替换随机数发生器以返回可控值、替换文件系统操作（如 os.Remove 等）防止真的删除文件、甚至替换内部调用的私有函数等等。Gomonkey 支持对函数、方法、全局变量甚至未导出函数打桩（后者通过 ApplyPrivateMethod 等实现） 。这使我们能够应对几乎所有类型的依赖替换需求，在不修改产品代码的情况下控制其行为。

然而，Gomonkey是一个强力但危险的工具，我们在实践中踩到过一些坑，需格外注意：

• 注意禁用内联优化：Go 编译器的内联优化可能导致函数被内联，从而没有真实的函数入口可替换。为确保打桩生效，运行 go test 时请加上参数：-gcflags=all=-l 关闭内联 。这是使用 gomonkey 的基本前提，否则某些函数可能怎么打桩都无效（尤其是简单的短小函数容易被内联）。
• 打桩非并发安全：Gomonkey 对函数入口做了底层修改，线程不安全 。如果有多线程并发执行打桩/恢复操作，可能引发不可预知的行为。经验法则是每个测试用例中仅创建一个 patches，并在 defer 中及时 Reset 。如需在并发场景下测试，尽量在单线程上下文使用打桩，或确保同一时间只有一个协程在操作桩。
• 作用域影响：补丁对全局函数的修改对整个进程有效。也就是说，一旦打桩，不仅当前测试，其他测试调用该函数也会受到影响。这就是为何我们要在测试结束时 Reset。推荐做法是在具体的 t.Run 子测试内使用打桩并及时恢复，避免影响同包内的并行测试。我们曾遇到因为一个测试忘记 Reset，导致后续测试拿到了桩函数返回值的情况，排查起来非常困难。
• 私有/未导出函数限制：根据 Go 语言特性，Gomonkey 无法对不同包的未导出函数进行打桩 （因无法在运行时获取其可访问符号）。对包内未导出的函数，Gomonkey 提供了 ApplyPrivateMethod 等曲折方法，但使用上需要传反射类型或指定字符串方法名，略有复杂度 。一般建议尽量将需要测试的函数提取为可导出（或接口），只有万不得已才用 Gomonkey 去碰未导出函数。
• 接口方法的打桩：Gomonkey无法直接针对接口定义进行打桩，因为接口本身没有具体实现。若需模拟接口的方法调用，应对其具体实现类型打桩 。比如接口 Fooer 有方法 Foo()，要打桩它的实现，需要拿到实现该接口的结构体类型，用 ApplyMethod 替换其 Foo 方法。很多时候更简单的做法是干脆使用前述 Mockery 来模拟接口，而不要使用 gomonkey 对接口方法下手。
  尽量避免打桩系统核心函数：虽然技术上可以 stub 一些标准库函数甚至底层函数，但这么做可能影响整个测试进程的行为，不可控风险高 。比如打桩 os.Exit、net/http 底层方法等就非常危险，有可能影响测试框架本身。对此，我的经验是补丁用在边界，不干预核心。针对标准库已有替代方案的场景，优先用依赖注入等方式重构代码，而不是一味 monkey patch。
• 系统兼容性：需要注意某些操作系统或处理器架构上，运行时修改函数可能受限制。例如在 macOS 上出于安全机制，Gomonkey 早期版本有无法工作的问题 。目前 amd64 架构 Linux/Windows 下使用通常没问题，但仍需留意官方更新和文档说明 。如果发现在特定环境下打桩不生效，可能不是用法问题，而是系统不支持，这种情况就只能考虑其他测试替代方案了。
  总的来说，Gomonkey 提供了动态篡改代码行为的能力，使得那些难以控制的函数调用也能被纳入测试掌控范围。在实际使用中，我们通常将 Gomonkey 和 Mock 工具配合：接口依赖用 Mockery，非接口依赖用 Gomonkey。下一节我们将展示一个二者结合的完整示例。

Mockery 与 Gomonkey 组合实战

下面通过一个完整示例，演示如何结合 Mockery 和 Gomonkey 对复杂场景进行测试。假设我们有这样一个函数 CanPlaceOrder，用于判断用户是否可以下单：

// 被测代码示例：
type User struct {
    MembershipExpire time.Time
}
type UserService interface {
    GetUser(uid string) (*User, error)
}
func CanPlaceOrder(us UserService, uid string) bool {
    user, err := us.GetUser(uid)
    if err != nil || user == nil {
        return false
    }
    // 用户会员未过期才能下单
    if time.Now().After(user.MembershipExpire) {
        return false
    }
    return true
}

这个函数有两个依赖：一个是接口 UserService（用于获取用户信息），另一个是调用了系统时间 time.Now。在测试中，我们希望模拟 UserService 接口，并控制时间进程来测试不同过期情况。以下是对应的测试代码：

import (
    "testing"
    "time"
    "github.com/stretchr/testify/assert"
    "github.com/agiledragon/gomonkey/v2"
    "project/mocks"  // 假设这里 mocks 包内有 UserService 的 mock
)
func TestCanPlaceOrder(t *testing.T) {
    // 1. 准备阶段：创建 UserService 模拟对象和时间桩
    dummyUser := &User{ MembershipExpire: time.Date(2025, 7, 1, 0, 0, 0, 0, time.UTC) }
    userSvcMock := new(mocks.UserService)  
    userSvcMock.On("GetUser", "user123").Return(dummyUser, nil)  // 模拟返回有效用户
    // 打桩 time.Now() 使其返回一个在会员过期之前的时间
    patches := gomonkey.ApplyFunc(time.Now, func() time.Time {
        return time.Date(2025, 6, 1, 0, 0, 0, 0, time.UTC)
    })
    defer patches.Reset()
    // 2. 执行被测函数
    result := CanPlaceOrder(userSvcMock, "user123")
    // 3. 断言结果并验证依赖调用
    assert.True(t, result)                       // 未过期，应允许下单
    userSvcMock.AssertExpectations(t)            // 验证 GetUser 模拟被正确调用
}

在这个测试中，我们完成了以下工作：

• 模拟 UserService 接口：通过 Mockery 生成的 mocks.UserService 对象，设定 GetUser 方法在接收到 “user123” 参数时返回 dummyUser 和 nil 错误 。这样被测函数调用 us.GetUser("user123") 时会拿到我们预置的用户数据。
• Monkey Patch 系统时间：使用 Gomonkey 将 time.Now 替换为返回 2025 年 6 月 1 日 的桩函数 。根据 dummyUser 的 MembershipExpire（2025 年 7 月 1 日），此桩使得 time.Now() 永远落在会员有效期内。
• 执行功能并断言：调用 CanPlaceOrder 后，我们期望结果应为 true（因为用户存在且未过期）。断言结果为 true 后，我们也用 AssertExpectations 校验了模拟对象的交互是否符合预期。

如需测试会员过期的场景，也很简单：只需调整桩函数返回一个晚于 7 月 1 日的时间，然后期望 CanPlaceOrder 返回 false 即可。通过这种方式，我们可以方便地为不同时间情景和不同依赖返回编写测试用例，而无需真的等待时间流逝或调用真实服务。

这个示例体现了 Mockery 与 Gomonkey 联合使用的威力：前者隔离外部依赖，后者掌控环境变量，共同使单元测试可以覆盖各种极端和复杂的情况。在我们的实践中，这种组合极大提升了测试的灵活性。例如测试一个函数既调用数据库又依赖当前日期时，我们就会同时用 sqlmock（数据库接口的 mock）和 Gomonkey 来完成双重替换，从而完全模拟出我们想要的场景。这套方案虽然强大，但也要求编写测试的人对系统依赖有清晰认识，明确哪些该 mock、哪些该打桩，以及如何搭配使用。

小结：当面对复杂场景时，不妨将Mockery和Gomonkey结合起来：接口依赖部分用 Mockery 生成假对象来控制行为，无法通过接口抽象的部分用补丁来控制。这使得单元测试几乎无所不能，可以在不改动产品代码的情况下测试各种情形。当然也要牢记上节提到的注意事项，合理管理桩的作用范围，避免引入新的不确定因素。

用单元测试保障存量代码改动稳定

单元测试的另一个重要价值体现在长期迭代中对存量代码改动的保护上。

随着业务发展，代码库不断演进，旧有模块可能需要修改以支持新需求。如果缺乏完善的单测，开发者对修改往往心存顾虑，生怕一不小心改坏了原来的功能。这种情况下，健全的单元测试套件就是我们的“安全网”。

我们的实践是：任何对已有功能的修改，首先运行一遍相关单元测试。如果某个改动导致之前通过的测试用例失败，那立即表明此改动引入了行为变化（要么是改动不当引入了 bug，要么是更新了业务逻辑，需要同步更新测试预期）。通过这种方式，单元测试可以充当回归测试的角色。

为了强化这种保障机制，我们还在 CI 流水线中加入了增量覆盖率统计和覆盖率检查。具体做法是：每次流水线准入测试时统计新增代码的覆盖率并发到通知，在提测前校验覆盖率不能低于约定指标(如 60%)，若不达标则拒绝提测。这样确保了无论老代码是否有测试，新提交的代码一定要有。长此以往，项目的整体测试覆盖率和代码质量都会稳步提升。

单元测试对存量代码的保护作用还表现在重构信心上。当我们计划对老代码做架构调整或性能优化时，往往会先看该模块的单测是否齐全。如果关键路径都有单测覆盖，我们就有底气大胆重构，然后通过跑测试验证行为不变。 正如业界所言，完善的单元测试可以支撑重构（Refactoring with safety net）。反之，如果某块代码没有任何测试，我们在修改时就如履薄冰，只能寄希望于手工测试或上线后观察，这无疑增加了风险。

总而言之，单元测试为存量代码的演进提供了稳定性保证：每当你修改代码，测试用例会第一时间告诉你改动是否影响既有功能。我们也应养成在改动既有功能时先跑测试、勤跑测试的习惯，把单测当作开发过程的必备步骤。

AI 辅助写单测的优缺点分析

随着 AI 技术的发展，我也尝试过使用AI工具（如字节跳动的 Trae 智能编程助手等）来辅助编写单元测试。这里结合使用 Trae 的体验，谈谈我个人对AI 写单测的感受。

AI 助力的优点：

• 提高编写效率：借助大模型对代码的理解能力，AI 工具可以根据被测代码或需求描述，自动生成初步的测试用例代码。这在一些样板式的测试场景下尤其有用。例如 Trae 提供了选中函数自动生成测试用例的功能，能够分析函数逻辑并产出对应的测试代码 。很多时候，AI 给出的测试用例已经包含了基本的 Arrange-Act-Assert 结构和主干逻辑，开发者只需稍加修改即可使用。我实际使用发现，对于简单的业务函数，AI 生成单测的速度远超人工编写，经常是函数写好后一键就出测试雏形，大大节省了时间。
• 覆盖建议全面：智能助手通常内置了一些测试设计的启发规则，比如识别边界值和异常分支等 。Trae 等工具声称能够自动识别代码中的边界条件并生成边界值测试 ，也会根据函数依赖推荐适当的 Mock 策略。这意味着 AI 可能帮我们想到一些遗漏的情况。例如一个字符串处理函数，AI 会考虑空字符串、特殊字符等边界，这在人工编写时有时会疏忽。借助这些建议，我们的测试用例集可以更加全面可靠。
• 降低上手难度：对于测试新手或不熟悉某些测试框架的人，AI 生成的用例起到了示范模板的作用 。例如 在生成测试时，会自动套用项目使用的测试框架和断言库，让新手省去了查文档和到处找示例的时间。一些繁琐的语法细节（比如如何初始化测试对象、如何调用 mock 方法等）AI 都帮你写好了，开发者可以专注于测试逻辑本身 。可以说，AI 辅助让“不会写单测”不再是借口，因为哪怕不知道从何下手，也可以让 AI 给出一个初稿再逐步完善。
• 结合文档生成测试：像 Trae 这样的智能 IDE 甚至支持根据产品需求文档或注释来生成测试 。测试智能体能够读取需求描述，推断出一些关键用例场景然后生成代码。这有点类似于基于规约的测试，确保代码实现符合需求预期。这种模式下，AI 生成的测试用例本身也可以看作需求的自动化验证。我们试用发现，对于明确写出输入输出要求的功能，AI 确实能生成贴合需求的测试用例，减少了我们手工设计用例的工作量。
  综上，AI 写单测最直观的优势就是省时省力且相对全面。正如 Trae 文档所说，它的 AI 能让开发者“专注于测试逻辑设计，而不是繁琐的语法细节” 。在实际项目中，我们感觉 AI 更像一个聪明的助手：帮你把简单重复的部分先搭好，让你不用从零开始。

AI 自动生成单测的缺点和局限：

• 生成结果良莠不齐，需要人工把关：AI 并不总是能理解代码意图，有时生成的测试用例只是机械地按照代码逻辑写一遍，对真正的需求点检验有限。这种情况下，测试可能始终绿灯，但其实并未覆盖潜在缺陷点，相当于“假绿”。我们曾让 ChatGPT 类模型为一个复杂函数写单测，结果生成的断言基本都是在验证函数直接输出的值等于它内部计算的值，缺乏对业务正确性的判断。这类单测即使通过，也不能说明代码没有问题。 有博主指出，大模型默认给出的单测“基本上能用的只有框架，里面的逻辑和 mock 全部都要大改”，提升效率有限 。可见AI 输出需要人为审核和修改，不能全盘接受。
• 缺乏业务语义，误判预期：AI 主要基于训练语料和代码模式来推断逻辑，对于业务含义较强的场景往往不理解，导致断言的预期值不正确。比如业务上某输入应该得到错误，但 AI 不了解这个规则，可能会按一般情况写成通过的测试。我们在使用 Trae 生成一些带业务规则校验的测试时，就发现生成的期望值常常反了，需要我们依据需求修改。AI 不懂你的业务背景，所以生成的测试用例不一定符合真实需求，需要开发者根据知识补充调整。
• 对依赖环境认识有限：虽然 Trae 等号称会推荐 Mock 策略，但实践中如果被测代码涉及复杂的外部依赖（数据库连接、消息队列等），AI 未必知道如何正确地模拟。 提到如果提示不明确，AI 往往“偷懒”，可能直接调用真实依赖或者忽略错误处理部分。这就需要我们在 prompt 中提供额外信息或自己动手改写。也就是说，AI 在处理复杂集成场景时能力有限，往往还是要靠开发者自己写底层依赖的替身代码。
• 可能引入不稳定因素：有时 AI 生成的用例本身不够健壮，或者对时间、随机性等因素处理不当，导致测试用例不稳定。比如我们试过让 AI 写多线程场景的测试，它直接在线程里用 time.Sleep 等待结果，导致测试偶尔超时失败。又比如生成涉及浮点数计算的断言，没有考虑误差范围。这些坑如果开发者不审查就直接引入项目，反而会降低 CI 的稳定性。因此我们对 AI 产出的测试也要像审查普通代码一样审查，必要时增加同步机制或误差范围等，避免日后成为“伪阳性”的失败案例。
• 依赖提示和语料：AI 能生成多好的测试，很大程度上取决于你如何提问和项目是否有良好注释。我们发现，当我们精心编写 Prompt，给出清晰的规则和上下文时，AI 给出的测试才相对靠谱 。这意味着需要花时间摸索提示工程，有时甚至要为 AI 写一份测试设计指南，然后让它遵循 。对于赶时间的任务，这额外成本未必划算。另外，如果项目代码风格特殊或缺少注释，AI 生成的内容可能会张冠李戴。所以，AI 不是万能，一定程度上仍依赖于现有代码质量和我们的引导。

总体而言，我们把 AI 当作单元测试编写中的一剂“辅助良药”，但不是可以完全撒手不管的工具。它的优点在于加速和启发：加速了测试样板的书写，启发了某些可能遗漏的测试点。但它的产出需要经验丰富的开发者review和调整，才能真正融入高质量的测试套件中。根据我使用 Trae 的心得：AI 最适合用来生成简单场景的测试或测试框架代码，比如大量参数组合的表格驱动测试、重复性的接口测试等，可以交给 AI 自动生成初稿，再由人校正细节。而对于核心复杂逻辑、涉及业务判断的部分，还是需要测试设计者认真思考，确定边界和预期，再决定让 AI 写什么、怎么写。

最后提醒一句，不要对 AI 抱有编写完美单测的幻想。它更像是聪明的脚手架，能帮你搭起架子，但建筑的精细程度和牢固程度，仍掌握在开发者自己手中。开发者与 AI 协作的平衡点是，让 AI 做擅长的体力活，把脑力活和判断力留给自己。只有这样，才能既享受到AI带来的效率提升，又保证单元测试的质量过硬，真正发挥单测在质量保障中的价值。