AI 编程中的环境型夹具：让测试从已知条件出发

AI 生成测试并不意味着测试结果天然可信。数据库内容不断变化、外部服务响应不稳定，或登录态与临时目录没有统一管理，都可能让同一段代码得到不同结论。要识别代码中被模型忽略的隐含假设，需要先控制测试环境，再分别处理数据、依赖和运行条件。

上一篇介绍了数据型夹具，还有一类管的是环境：让测试在可重复的条件下运行——固定的数据库、可控的依赖、统一的运行条件。下面介绍三种常用的环境型夹具——数据库、测试替身、环境夹具，看看它们各是什么，以及在 AI 编程里能派什么用场。

一、数据库夹具

很多代码的行为，取决于数据库里装着什么。数据库夹具的做法是：测试前把一批已知的数据装进测试库，测完再清理。讲究一点的就用“事务夹具”：测试期间的改动，在事务结束时自动回滚，不会污染其他测试。它用在集成测试和功能测试上——这两类测试都需要每次面对一模一样的数据。缺点是装拆慢，数据一多，维护就成了体力活。在验证 AI 代码上，它的作用是把 AI 生成的逻辑放进真实数据里检验：AI 常常想当然地假设数据库里有什么，而实际上可能有空字段、脏字段、或者缺字段；把真实数据装进夹具，AI 隐藏的那些假设就会被暴露出来。

二、测试替身

“测试替身”是一个总称，是指不使用真实的组件，而用一个替身来代替。常见的主要有下面几种：

• 哑对象（dummy）：只占个位置，但实际并不使用；
• 存根（stub）：预先写死返回值，让调用方得到的结果固定；
• 涧谍（spy）：照常运行，但会记录调用方式；
• 模拟对象（mock）：需要按预期的方式调用，方式不对立马报错；
• 假实现（fake）：真的能运行，但用的是简化逻辑。

还有一个实用的做法是“时间冻结”：把时钟换成替身，测试永远在同一个时间，适合验证超时、过期这样的逻辑。但要注意的是：替身太多，测试会脱离真实环境，得出的结论不够真实。在验证 AI 代码上，替身尤其要谨慎：AI 既能写代码也能写替身，如果它顺手 mock 掉一个外部服务，就可能把“被 mock 的行为”和“真实服务的行为”混为一谈。这一点尤其要小心检查。

三、环境夹具

这里设置的不是数据，而是运行条件：临时目录、登录态、浏览器会话、日志捕获。测试框架普遍提供生命周期机制：pytest 的夹具能按函数、模块、会话分级，还可以互相套用；Playwright 分得更细，有“整个进程共用一份”的 worker 级和“每个测试新建”的用例级。它适合上千个用例共享同一份初始化，样板代码只写一次。在验证 AI 代码上，它同时服务于两端：一方面给 AI 生成的测试提供稳定的运行环境；另一方面，这些夹具本身是“沉淀下来的知识”，把团队认可的初始化方式固化下来，AI 生成测试时直接引用，而不是每次临场发挥，编一份可能出错的假数据。

小结

三种环境型夹具，各管一块：数据库夹具保证数据稳定，测试替身隔离外部依赖，环境夹具统一运行条件。搭配上篇讲的数据型夹具，就可以让每次测试都从“已知的起点”出发。在 AI 编程里，它们的角色多了一层：把 AI 生成的代码和测试放回受控的、已知的环境里检验，防止模型用自己编造的假设给自己打分。原则只有一条：每次测试都从已知的起点出发；替身要克制，数据库要真实。

AI 编程里的数据型夹具