破损、陈旧或丢失？在项目级测试演化上对 编码智能体 进行基准测试

随着生产代码的发展，测试套件必须共同发展才能保持有效。现有的测试演化基准在方法级粒度上运行，具有预先配对的输入，绕过了从整个项目中定位受影响测试的任务，并完全排除了对新测试的需要。我们推出了 TEBench，这是第一个用于测试演进的项目级基准。给定项目存储库和代码更改提交，TEBench 要求系统自主识别需要修改的测试，确定需要新测试的位置，并生成相应的测试补丁。我们通过 Defects4J 项目的四阶段管道构建 TEBench，使用开发人员编写的 真值 管理来自 10 个项目的 314 个任务实例。每个实例都用三种演变类型中的一种或多种进行注释：测试破坏（失败的测试）、测试过时（通过但不再有意义地验证更新的行为的测试）和测试缺失（引入的行为所需的新测试）。我们评估了涵盖三个工业代理框架（Claude Code、Codex CLI、OpenCode）的七种配置和六种基本模型以及启发式基线。所有七种配置都集中在 45.7% 到 49.4% 的识别 F1 上，揭示了框架和基本模型之间共享的性能上限。 Test-Stale 是最具挑战性的类型，平均 F1 约为 36%，因为配置依赖于执行失败信号并且缺乏主动语义推理。在更新任务中，配置产生高度可执行的测试修改，其表面形式与 真值 有很大不同。轨迹分析揭示了一个反应性的“执行-失败-修复”循环，它成功地破坏了测试，但在结构上无法解决陈旧或丢失的测试。 TEBench 位于 https://github.com/iSEngLab/TEBench，排行榜位于 https://tebench-leadership.vercel.app。