技术摘要：编码智能体是否正在生成过度模拟（Over-Mocked）的测试？一项实证研究

问题陈述

虽然大语言模型（LLMs）已被广泛应用于软件工程任务，但自主编码智能体（如 Claude Code、GitHub Copilot Agent、Cursor Agent）的出现代表了一次重大转变。与传统的代码补全工具不同，这些智能体具有高度的自主性，能够调用外部工具、执行代码并在软件仓库中撰写提交（commits）。关于其采用的一个关键担忧是它们自主生成的软件测试质量。

具体而言，本文探讨了**过度模拟（over-mocking）**的问题。虽然模拟（mocking）是隔离依赖项并确保测试确定性的标准技术，但过度使用会导致测试难以理解、难以维护，且在验证真实系统交互方面的效果较差。尽管之前的研究已经探讨了 LLM 生成的测试质量（例如：易变性、缺乏断言），但关于自主智能体在现实世界系统中生成模拟的具体行为，目前仍缺乏深入研究。作者指出，有轶事证据表明，智能体生成的模拟比人类开发者更多，但此前缺乏实证验证。

研究方法

本研究是对托管在 GitHub 上的软件仓库进行的规模化实证分析，重点关注 2025 年的数据。

• 数据集范围： 研究人员分析了 2,168 个仓库中的 1,254,878 次提交，涵盖 Python、JavaScript 和 TypeScript 语言。
• 智能体识别： 仓库的选择基于是否存在与领先智能体相关的配置文件或目录（例如 CLAUDE.md、.cursor/、copilot-instructions.md）。通过搜索提交元数据（作者和 Co-authored-by 标头）中的关键词（如 "claude"、"copilot" 和 "cursor"）以及其他工具（如 Aider 和 Devin AI）来识别智能体提交。
• 测试检测： 测试提交通过标准的文件命名约定（如 test_*.py、*.test.ts）和源自流行框架（如 Pytest、Jest、Mocha）的目录模式（如 __tests__/、spec/）进行识别。
• 模拟检测： 研究将“模拟提交”定义为引入了新测试双胞胎（test double）标识符的提交。检测方法通过扫描包含 mock、stub、spy、fake、dummy 等术语的标识符以及特定的 Python 装饰器（如 @patch），捕捉了包括基于框架的模拟（如 MagicMock、spyOn）和手动创建的测试双胞胎。
• 研究问题 (RQs)：
  • RQ1： 编码智能体生成测试的频率如何？
  • RQ2： 编码智能体在测试中生成模拟的频率如何？
  • RQ3： 编码智能体生成哪些类型的测试双胞胎（dummy, stub, spy, mock, fake）？

统计分析包括用于独立性检验的卡方检验、配对 Wilcoxon 检验以及用于衡量效应量的 Cliff's delta。

关键结果

RQ1：测试生成的频率

• 更高的测试参与度： 编码智能体修改或添加测试文件的可能性显著高于非智能体。智能体提交中涉及测试文件的比例为 23%，而非智能体为 13%。
• 仓库普遍性： 60% 存在智能体活动（agent activity）的仓库也包含了智能体生成的测试活动。
• 时间趋势： 在 2025 年创建的仓库中，智能体进行的测试提交比例上升至 17%（相比之下，整体数据集为 7%），表明对智能体处理测试任务的依赖程度正在增加。

RQ2：模拟生成的频率

• 更高的模拟率： 编码智能体在其测试提交中引入模拟的可能性更高。智能体测试提交中添加模拟的比例为 36%，而非智能体为 26%。
• 仓库相关性： 68% 具有智能体测试活动的仓库也包含了智能体模拟活动。
• 活动水平： 在高强度智能体活动（≥50 次智能体提交）的仓库中，智能体的模拟提交比例为 36%，显著高于同一仓库中非智能体的 28% 比例。
• 时间趋势： 与测试生成类似，在 2025 年创建的仓库中，模拟提交的比例上升至 19%（整体为 9%）。

RQ3：生成的模拟类型

• 缺乏多样性： 编码智能体主要使用 mock 类型（占其测试双胞胎使用的 95%）。
• 与人类对比： 非智能体使用更多样化的测试双胞胎，包括使用 mock (91%)、fake (57%) 和 spy (51%)。
• 利用不足的类型： 智能体和人类很少使用 dummy 和 stub 类型，但智能体表现出向通用的 "mock" 类别高度集中的倾向，这表明其隔离策略缺乏细微差别。

核心贡献

1. 首次关于智能体生成模拟的实证研究： 本文提供了对现实世界软件系统中自主编码智能体生成的测试中，模拟的存在性和频率进行的首次大规模调查。
2. 具有实践意义的启示： 研究结果为从业者和研究人员提供了具体的发现，强调智能体不仅在编写代码，而且正在积极地扩展测试套件，并表现出过度模拟的倾向。

重要性与影响

论文得出结论，编码智能体正在积极重塑软件测试实践，但也带来了有关测试质量的潜在风险：

• 自主测试潜力： 智能体生成的测试提交的高频率表明，这些工具正被用于维护和扩展测试套件，而不仅仅是生产代码。
• 过度模拟风险： 智能体过度依赖模拟（36% vs 26% 对于人类）以及仅使用单一测试双胞胎类型（mock）的倾向，表明它们生成的测试可能更容易自动生成，但在验证真实交互方面效果较差。这种“过度模拟”可能导致即使底层实现错误，只要模拟内容与（可能已过时的）模拟定义相匹配，测试仍能通过。
• 配置指导： 作者认为，由于智能体依赖配置文件（如 CLAUDE.md、copilot-instructions.md），从业者必须在这些文件中明确包含关于模拟最佳实践和反模式的指导。研究发现，虽然这些文件中常见的测试相关指令，但特定的模拟相关指导却较少。
• 未来研究： 本文呼吁进一步调查智能体生成测试的质量及其特定模拟策略对可维护性和覆盖率的影响。同时，建议探索智能体配置文件的内容，以了解指令如何影响测试生成。

该研究强调，虽然智能体提供了显著的自动化潜力，但“增强型编码的代价是永恒的警惕”，特别是在自动化测试套件中验证真实交互方面。