[Paper] 破坏、陈旧或缺失？基准测试 Coding Agents 在 Project-Level Test Evolution 上

Source: arXiv - 2605.06125v1

概述

本文介绍了 TEBench，这是首个评估编码代理在 项目级 测试演进上的基准。TEBench 并不向代理预先指定要修复的方法，而是要求它们扫描整个代码库，识别代码变更后哪些测试失效、变得陈旧或缺失，然后生成相应的测试补丁。这一转变映射了真实的开发周期，工程师必须让测试套件与不断演进的生产代码保持同步。

关键贡献

• 项目级基准：来自 10 个 Defects4J 项目的 314 个精心挑选的任务实例，每个实例均配有真实的开发者提交和真实的测试变更。
• 三类演进：
  1. 测试破坏 – 更改后导致现有测试失败。
  2. 测试陈旧 – 测试仍然通过，但不再验证预期行为。
  3. 测试缺失 – 对新引入的功能需要全新测试。
• 端到端评估流水线：代理必须 (a) 定位受影响的测试，(b) 决定需要新增测试的地方，(c) 生成语法正确的测试补丁。
• 全面的实证研究：七种配置，涵盖三种工业级基于 LLM 的编码代理（Claude Code、Codex CLI、OpenCode）和六个底层模型，以及一个启发式基线。
• 开放资源：基准代码、数据以及用于持续社区贡献的公开排行榜。

方法论

1. Data construction – 从 Defects4J 开始，作者提取了修改生产代码且由开发者编写的相关测试更改的提交。一个四阶段流水线对这些提交进行过滤、去重和标注，最终得到 314 个实例。
2. Annotation of evolution types – 基于 diff 分析和人工验证，每个实例被标记为包含三种测试演化类别中的一种或多种。
3. Agent task definition – 对于给定的仓库快照和目标提交，代理必须输出：
   • 需要修改（或删除）的现有测试文件列表。
   • 需要创建的新测试文件列表。
   • 这些测试的具体代码补丁。
4. Evaluation metrics –
   • Identification F1：衡量正确识别破坏性、陈旧和缺失测试的精确率/召回率。
   • Patch executability：生成的测试代码是否能够编译并运行。
   • Semantic similarity：与开发者真实补丁的表层形式距离（用于分析，而非主要评分指标）。
5. Baseline & agents – 一个简单的启发式方法，将任何在修改代码上失败的测试标记出来，作为下界。七种 LLM 配置使用相同的提示词和温度设置运行，以确保公平比较。

结果与发现

关键要点

• 所有代理在相似的性能上限处收敛，表明当前 LLM 的瓶颈更多来自任务的表述方式，而非模型规模。
• “execute‑fail‑fix” 循环占主导：代理首先运行测试套件，检测失败，然后生成修复。这对 breaking 测试有效，但对 stale 或 missing 测试没有信号，因而这些类别的 F1 较低。
• 生成的补丁往往语法正确，却与开发者的真实答案差距很大，说明代理在解决 症状（让测试通过），而不是复现原始测试的 意图。
• 启发式基线虽然简单，却已经捕获了大量的 breaking 测试，凸显失败信号是当前代理的主要驱动因素。

Practical Implications

• CI/CD 工具 – 集成兼容 TEBench 的代理可以在拉取请求后自动发现破坏性测试，减少人工分拣时间。
• 测试维护助手 – 该基准突显了需要能够推理测试相关性（陈旧性）并建议新测试的代理，这一能力可直接提升大型代码库的回归测试效率。
• 模型驱动的代码审查 – 开发者可以提前收到测试补丁的建议，尤其是针对明显的破坏性更改，从而加速反馈循环。
• 基准驱动的产品路线图 – 构建 AI 驱动开发者助手的公司现在拥有一个具体的、项目规模的指标，用于跟踪超越方法级代码生成的进展。
• 开源贡献 – 由于 TEBench 公开可用并设有排行榜，团队可以将自有代理与社区基准进行对比，促进竞争性改进。

限制与未来工作

• Dataset size & diversity – 虽然 314 个实例覆盖了十个项目，但基准仍然只反映了有限的语言集合（主要是 Java）和项目结构。
• Reliance on execution failures – 目前的 agent 偏向于仅检测导致测试失败的情况；需要更丰富的语义信号（例如 change‑impact analysis、specification mining）来处理陈旧和缺失的测试。
• Ground‑truth focus on developer patches – 评估将开发者的确切测试视为黄金标准，这可能会惩罚 agent 产生的有效替代测试设计。
• Scalability to massive monorepos – 基准未在包含成千上万测试的仓库上测试 agent，在这种环境下搜索和 ranking 变得至关重要。
• Future directions suggested by the authors include: 扩展到其他生态系统（Python、JavaScript），结合静态分析在没有 execution failures 的情况下发现陈旧测试，以及设计结合 impact analysis 与测试生成的 multi‑step prompting strategies。

作者

• Ye Shang
• Quanjun Zhang
• Haichuan Hu
• Chunrong Fang
• Liang Xiao
• Zhenyu Chen

论文信息

• arXiv ID: 2605.06125v1
• 分类: cs.SE
• 发表日期: 2026年5月7日
• PDF: 下载 PDF