XRepoTest：面向大语言模型的多语言仓库级单元测试生成基准（中文全译）

XRepoTest：面向大语言模型的多语言仓库级单元测试生成基准（中文全译）

翻译说明：本文是 arXiv 论文 XRepoTest: Benchmarking Multilingual Repository-Level Unit Test Generation for Large Language Models（arXiv:2608.25939，v2）的中文全译，由智测团队翻译。原作者：Dung Le Quang、Dong Cao Van、Nam Le Hai、Linh Ngo Van、Anh M. T. Bui（Hanoi University of Science and Technology，越南）、Phuong T. Nguyen（University of L'Aquila，意大利）。原文以 CC BY 4.0 许可发布，允许翻译与再分发，须署名。译文保留原文全部章节、核心数据与结论；参考文献列表、文内引注编号，以及仅存在于原文附录（A–K）的完整逐模型数据表从略，正文中予以指明。模型名、工具名、基准名、指标名保留英文。图 1、图 2 随文保留，版权归原作者。

摘要

大语言模型（LLM）在自动化单元测试生成上已显示潜力，但现有评估大多依赖独立（standalone）设置和一组狭窄的编程语言，高估了其真实世界的就绪度。我们提出 XRepoTest，一个用于单元测试生成的多语言（即覆盖多种编程语言）仓库级基准，横跨五种研究不足的语言：Rust、Go、Julia、PHP 和 Ruby。XRepoTest 用一个容器化执行框架和多种上下文增强策略（包括文件级、基于 LSP 和基于检索的上下文），在真实的仓库约束下评估测试。除测试通过率和覆盖率等标准指标外，我们提出调用率（Invocation Rate，IR）来评估生成的测试是否有意义地演练了预期功能。对 14 个最先进 LLM（如 Claude 4.5、GPT-5.2、DeepSeek V4-pro 和 Qwen 系列）的实验揭示了独立设置与仓库级性能之间的重大差距，以及更丰富上下文与测试可靠性之间的权衡。总体而言，XRepoTest 提供了一个有挑战、信息丰富的基准，以推进真实软件环境中可扩展、稳健的单元测试生成。数据集与代码公开可得。

1 引言

编写单元测试是软件开发中耗时却关键的一部分；研究估计它可能占开发者约 15% 的时间。这激发了数十年的自动化单元测试生成研究。传统方法（如基于搜索、符号或随机测试生成）能产出覆盖率合理的测试，但这些自动生成的测试常受可读性差、断言琐碎或无效的困扰。近期，大语言模型（LLM）作为有前景的替代方案出现，显著加速了单元测试生成，并常产出更自然、类人的测试用例。虽然 LLM 已被广泛用于单元测试生成，它们的评估在实际适用性和多语言适应性上仍面临重大挑战。现有测试生成基准常无法反映真实的仓库级约束，并偏向一小组编程语言，限制了我们对 LLM 在领域特定、语言多样的软件系统中如何表现的理解。

第一，各种现有单元测试生成基准在独立的、函数级运行，把代码从真实测试被编写和执行所在的仓库上下文中隔离出来。在这些设置中，模型无需与真实的构建系统、依赖图或框架约定交互，导致对实际部署就绪度的虚高印象。图 1 展示了这一差异：独立基准（即 McEval）上的强性能，当测试必须在真实仓库内生成和执行时，会大幅高估模型有效性。在仓库级设置中，模型不仅要写出语法貌似合理的测试，还要解析项目特定的依赖、遵循框架约定、满足构建系统，并在上下文不完整时构造有效输入和断言。这些要求急剧降低了可行性和语义正确性，揭示出独立成功与真实世界单元测试生成之间的持续差距。

第二，虽然一些近期框架和基准考虑了仓库级测试生成场景，它们仍不成比例地集中在 Java 和 Python 上。这种狭窄的语言聚焦限制了跨多样编程生态对基于 LLM 的测试生成方法的评估，阻碍了可泛化、在多语言软件环境中实际有用的工具的开发和评估。同时，不同编程语言表现出独特特征和领域特定的使用模式。例如，Rust 已迅速成为内存安全系统编程的标准选择；Go 支撑了大部分云原生基础设施；Julia 正推动高性能科学计算的进展；PHP 和 Ruby 继续驱动相当一部分生产 Web 应用。这些语言还引入独特的技术挑战，例如 Rust 的所有权和借用模型，可能使在更常规语言设置中有效的生成策略失效。

为弥合这些差距，我们提出 XRepoTest——一个用于单元测试生成的大规模多语言仓库级基准，横跨五种高影响但研究不足的语言：Rust、Go、Julia、PHP 和 Ruby。（本文中「多语言」指覆盖编程语言，而非自然语言。）XRepoTest 提供丰富的仓库上下文，并系统评估多种上下文策略，包括基于检索、文件级和基于 LSP 的增强，揭示测试有效性与调用可靠性之间的权衡。此外，我们提出调用率（IR）作为通过率和覆盖率的补充指标，使对生成测试是否真正演练预期功能的评估更忠实。我们的全面实验揭示：在标准设置下，性能主要受 API 幻觉的瓶颈限制；而增强上下文虽改进通过率和覆盖率，却常引入降低 IR 的噪声，凸显测试有效性与可靠性之间的复杂权衡。

综上，我们的贡献如下：

• 多语言仓库级测试生成基准：我们提出 XRepoTest，一个由来自真实 Rust、Go、Julia、PHP 和 Ruby 仓库的超过 3,642 个焦点函数构成的精选基准，设计来反映这些生态中多样的真实项目代码和测试约定。
• 全面评估框架：我们提供一个容器化评估框架，自动设置并跨所有所考虑语言执行生成的测试。我们的框架用四个标准指标实现可靠的、基于执行的评估：测试通过率（TPR）、编译成功率（CSR）、行覆盖率和变异分数；并引入新颖的调用率（IR）来识别测试通过但未能有意义演练焦点函数的情形——这些情形可能引入低质量测试和技术债。
• 仓库感知上下文：为检查不同上下文的影响，我们的框架和数据集提供丰富的元数据和工具，支持静态和动态上下文增强。静态上下文包括文件级上下文和基于 LSP 的符号解析（如参数类型和依赖定义），而动态上下文通过使用稀疏和稠密检索方法的检索增强途径实现。
• 广泛的 LLM 评估：我们在 14 个横跨系列和规模的最先进 LLM 上做了全面实验，评估多样的上下文配置。我们的分析揭示了当前模型的系统性优势和局限，并展示上下文设计如何关键地塑造生成测试的质量。

2 相关工作

自动化单元测试生成有悠久历史，横跨传统的基于搜索和启发式技术，以及更近期的 LLM 驱动方法。经典生成器能达成合理覆盖率，但常产出脆弱、低可读性、带琐碎或无信息断言的测试，限制了实际采用。相比之下，基于 LLM 的系统能生成更自然的测试脚手架和断言，并进一步纳入执行在环的修复或分析引导的提示以改进有效性。

从评估视角，若干高质量单元测试生成基准已纳入仓库上下文，如 Defects4J、Methods2Test 和 TestGenEval，但它们仍主要集中于 Java 和 Python 等高资源语言，限制了对其余生态的适用性。更近期，UniTSyn 引入了一个多语言测试生成框架；然而它的评估改编自独立代码生成基准，如 HumanEval-X 和 McEval，这些抽象掉了仓库级约束，因此对真实设置中测试生成方法的实际有效性提供的洞察有限。

除这些基准外，近期软件工程数据集日益瞄准更广的编码和软件演化任务，其中测试生成可能作为问题求解过程的一部分出现。SWE-Compass 跨任务类型和编程语言评估整体 agentic 编码能力，而 SWE-EVO 聚焦长时程、单语言（Python）的代码演化，以测试作为验证 oracle。测试生成的独立评估与这些更广设置互补，因为 XRepoTest 通过跨五个多样编程语言生态的细粒度、以焦点函数为中心的诊断，隔离了测试生成本身这一步骤。这补充了日益增长的专门测试生成基准（如 TestGenEval），以及更广的 agentic 软件工程套件。

多语言仓库级评估的空白。 尽管许多编程语言在实践中被广泛使用，在仓库级评估单元测试生成的基准在少数高资源生态之外仍稀缺。一个关键障碍在于构建可靠的执行环境，这需要对构建系统、测试框架和依赖配置的语言特定知识。为填补这一空白，我们提出一个大规模多语言、仓库级的测试生成基准和数据流水线，实现跨多样编程语言对测试生成模型的系统、可执行评估。

表 1：测试生成基准按语言、规模，以及对项目级函数（PF）、文件上下文（FC）、仓库上下文（RC）支持的比较

| 基准 | 语言 | 规模 | PF | FC | RC | |---|---|---:|:-:|:-:|:-:| | MBPP | Python | 500 | ✗ | ✗ | ✗ | | HumanEval | Python | 164 | ✗ | ✗ | ✗ | | TestEval | Python | 210 | ✗ | ✗ | ✗ | | McEval | 40 种语言 | 16,031 | ✗ | ✗ | ✗ | | SF110 | Java | 182 | ✓ | ✗ | ✗ | | Defects4J | Java | 357 | ✓ | ✓ | ✗ | | TestPilot | JavaScript | 1,684 | ✓ | ✓ | ✗ | | TestGenEval | Python | 1,210 | ✓ | ✓ | ✗ | | XRepoTest | Rust, Go, Julia, PHP, Ruby | 3,642 | ✓ | ✓ | ✓ |

3 方法

本节描述 XRepoTest 的构建及其上下文感知评估框架，随后概述数据集的规模、语言覆盖和领域分布。XRepoTest 是仓库级而非独立的：每个任务瞄准一个焦点函数，但生成的测试被插入原始项目环境并在其中验证。这些细节凸显了使 XRepoTest 成为评估基于 LLM 的单元测试生成之稳健基准的设计选择。

3.1 数据集构建

图 2 展示了 XRepoTest 的端到端工作流，它由三个概念阶段组成。第一，在基准构建期间，我们选择仓库并提取非平凡的焦点函数以形成核心基准。第二，在提示构建期间，每个焦点函数与从定义良好的上下文源提取的上下文信息配对，包括（i）作为基准一部分发布的静态上下文，以及可选的（ii）在评估时即时构建的基于检索的（动态）上下文。最后，生成的单元测试在容器化环境中执行和验证，以确保可复现的仓库级评估。流水线组件（包括过滤规则、上下文增强和容器化环境）的更详细实现见原文附录 B；数据污染风险的讨论见附录 C。

语言选择。 我们排除 Java 和 Python（因其已被广泛先前研究），转而聚焦 PHP、Go、Ruby 和 Rust——生产中广泛使用但在仓库级测试生成研究中仍研究不足的语言。我们还纳入 Julia，一个相对低资源、但采用和研究兴趣日益增长的语言。

仓库选择。 对每种语言，为确保质量和相关性，我们应用过滤标准，包括：至少 500 个 GitHub star、有明确定义的项目结构和构建配置文件（如 Cargo.toml、Project.toml、go.mod、composer.json 或 Gemfile）以最小化环境设置中的人工干预。此外，对每种语言，我们确保所选仓库横跨至少两个不同应用领域，以促进数据集多样性。遵循这一过程，我们为每种语言选择 6–10 个仓库，它们共同构成基准数据集的基础（每仓库的额外统计见原文附录 A.1 表 A.1）。

焦点方法提取。 从收集的仓库，我们用 tree-sitter 把源文件解析成抽象语法树（AST），实现语言无关的遍历和结构分析。从每个 AST，我们提取顶层函数和方法定义。为确保函数的质量和有效性，我们应用系统性过滤规则，强制：（i）最小代码长度，（ii）存在可观察输出（显式 return 语句），（iii）排除现有测试代码，（iv）语法有效性。这些标准帮助消除琐碎或退化的函数，同时保留适合单元测试生成的语义有意义的焦点方法。完整过滤规则详见原文附录表 A.2。

上下文增强。 为实现真实且灵活的仓库级测试生成，我们的框架支持静态和动态上下文增强。发布的 XRepoTest 基准提供精确、轻量的静态上下文：文件级上下文（即包含焦点方法的文件内容），以及通过语言服务器协议（LSP）解析参数定义、类型声明和相关被调用方签名的基于 LSP 的上下文。此外，遵循仓库级代码生成实践，XRepoTest 支持可选的基于检索的增强，其中稀疏（BM25）或稠密（UniXcoder）检索器动态地从仓库选择相关代码片段（即代码块）以丰富提示。

容器化执行环境。 所有生成的单元测试在 Docker 容器内执行，以跨语言标准化工具链、依赖安装和评估。每个仓库用其原生测试框架评估（如 cargo test、go test、Test.jl、PHPUnit、RSpec）。

总体而言，我们的流水线为仓库级单元测试生成提供了一个灵活、可扩展的基础。虽然本工作聚焦五种编程语言，该框架被设计为能以最小努力扩展到额外语言，只需有受支持的测试框架和恰当配置文件来设置执行环境。

3.2 数据特征

数据统计。 XRepoTest 横跨六个多样应用领域，反映所选编程语言间语言特定的使用模式。我们还额外确保每种语言的样本数量均衡，以支持多语言设置下公平、可比的评估。详细的仓库统计和领域分布见原文附录 A.1。

4 评估指标

标准指标。 为评估生成单元测试的有效性，我们采用先前自动化测试生成工作中常用的一组指标。测试通过率（TPR）衡量运行时正确性，即编译后的测试中无异常或断言失败地执行的比例。为评估语义覆盖，我们报告行覆盖率（Cov），它衡量焦点方法中被生成测试演练的行的百分比。我们还计算编译成功率（CSR）和变异分数；我们在 §5.1 报告两者的摘要，并在原文附录表 A.4 和 A.5 呈现完整的逐模型值。完整指标定义见原文附录 D。

新提出的指标。 标准评估指标，如 TPR、CSR 和 Cov，常无法区分意外执行和有意验证。我们观察到 LLM 频繁产出包含关键语义缺陷的「通过」测试， notably 是间接调用——焦点方法作为包装函数的副作用被执行，而非被显式瞄准。原文示例 4 提供了该问题的说明性例子，其中测试调用包装器 Circle 而非焦点方法 doSort。在这些场景中，覆盖率指标被虚高，把焦点方法记为「已覆盖」，尽管其特定逻辑从未被直接演练或断言。为弥合执行与意图之间的这一差距，我们引入调用率（IR）。这一指标显式验证生成的测试是否包含对被测焦点函数的直接调用。通过把这些误导性的间接调用与真正的单元测试区分开，IR 充当「行为相关性」的严格指示器，确保报告的高 TPR 和 Cov 分数确实反映模型与焦点方法互动的能力。IR 的实现详见原文算法 1。

这些指标共同为评估不同测试生成技术下生成单元测试的语法健全性和执行有效性提供了一个全面范式。

5 发现与讨论

5.1 XRepoTest 上跨 LLM 的性能

在这个实验中，我们用最小焦点/标准上下文（焦点方法和类签名）在 XRepoTest 上评估 14 个跨模型系列和规模的最先进 LLM，遵循先前研究。我们首先总结跨模型趋势，然后分析跨各语言的结果。XRepoTest 中所有语言在统一协议下用贪婪解码评估。模型和提示模板的细节见原文附录 A.11 和 K。

跨模型的整体趋势。 表 2 表明，单元测试生成在五种语言上仍具挑战，即使对前沿系统。跨语言，最强的模型往往是指令遵循的、在产出可执行测试脚手架上更可靠，但通过的测试仍受正确 setup 和 oracle 的瓶颈限制。模型系列效应显著：前沿模型（Claude 4.5 和 GPT-5.2）主导许多按指标的最高分，而强的开放权重基线（如 Qwen 变体和 GPT-OSS）保持竞争力。我们还观察到 GPT-5.2 在若干语言/指标上一致很强（如 Ruby TPR），但它并未在整套上均匀主导，强调测试生成能力仍不均匀。值得注意的是，最佳模型因语言和指标（如覆盖率对通过率）而异，强化了改进不均匀、且 XRepoTest 暴露出不同能力空白的结论。

辅助质量信号。 我们还报告编译成功率（CSR）和变异分数（MS），其完整逐模型值在原文表 A.4 和 A.5：平均而言，模型编译了 57.4% 的生成测试（CSR），并在 Go、Rust 和 Ruby 上达到平均 MS 3.2%（Ruby 的 MS 值是下界估计）。

语言特定性能与挑战：

• Rust：结果凸显一个脚手架瓶颈：模型频繁无法组装正确的 imports/crates 并满足严格的类型和所有权约束。即使强系统也常到达焦点方法，但不能可靠产出检查行为的测试。标准设置下，Claude 4.5 Sonnet 达成最佳 Rust 性能（TPR 12.78%、Cov 11.56%、IR 75.94%），而 GPT-5.2 达到 TPR 12.24% 和 Cov 9.31%。
• Go：模型达成比 Rust 更高的执行覆盖率，但通过的测试仍受正确 oracle 和 setup 的瓶颈限制，表明语义正确性是主要限制因素。GPT-5.2 在 TPR 上领先（25.78%），而 Claude 4.5 Sonnet 达成最高 Cov（43.53%），两个模型都保持近乎完美的 IR（≥98%）。
• Julia：性能中等：Claude 4.5 Sonnet 达成最佳 TPR（19.88%），GPT-5.2 达成最佳 Cov（31.92%），而小模型（如 Qwen3-8B 的 TPR 0.88%）远远落后。多数模型的 IR 很高（≥87%），尽管像 Qwen3-8B（73.83%）这样的较小模型是例外，表明焦点方法调用通常不是瓶颈——语义正确性才是。
• Ruby：结果明显分裂：GPT-5.2 在 TPR 上领先（25.78%）但只达成 7.80% Cov，而 Claude 4.5 Sonnet 在 Cov 上领先（14.25%）但 TPR 低得多（6.37%）。这一 TPR–Cov 分歧表明模型能演练代码路径却不产出通过的断言，反映了 Ruby 重 DSL 的测试约定的难度。
• PHP：Claude 4.5 Sonnet 以 TPR 26.93% 和 Cov 41.76% 主导，而 GPT-5.2（TPR 10.06%）和开放权重模型显著落后。多数模型的 IR 近乎完美（≥97%），尽管像 Qwen3-8B（22.91%）和 Kimi-k2.5（88.08%）这样的较小模型是显著例外，使 PHP 成为对有能力的模型而言调用最容易、但测试正确性仍是挑战的语言。

单元测试质量 vs 软件工程能力。 我们观察到 SWE-bench 性能与 TPR/Cov 之间的强正相关，表明从一般软件工程能力到测试生成的部分迁移。然而，相关是不完整的，这激发了像 IR 这样的补充指标。完整分析见原文附录 E.4。

主结果（标准设置，节选自原文表 2）——TPR / Cov / IR：

（Julia、Ruby、PHP 及全部 14 个模型、五种上下文设置的完整逐格数据见原文表 2，篇幅原因此处从略。）

5.2 上下文增强的影响

在前面分析的基础上，我们观察到模型在独立函数领域表现出色，但在需要更广项目级上下文时挣扎（图 1）。这种缺失的上下文常导致 API 幻觉（表 4），因为模型无法完全解析依赖或引用。本节我们调查上下文增强策略；更多实现细节见原文附录 B。

表 4：标准（Std.）与文件级上下文（Ctx.）设置下跨语言的失败模式分布（每列归一化到 100%；「无错误/通过」行捕捉通过所有检查、无任何失败的样本）

基于检索的增强。 检索方法跨语言和模型显示混合结果（原文表 3）。对配 Claude 4.5 Sonnet 的 Go、Julia 和 PHP，稀疏和稠密检索都相比标准设置改进了 TPR 和 Cov，但这些增益并不普遍：GPT-5.2 和 GPT-OSS 显示不一致的改进，而 Ruby 尽管有一些 TPR/Cov 增益却表现出 IR 下降。这种变异性表明检索有效性严重依赖模型架构和语言特征。这些检索配置是标准参考设置而非按模型调优的；结果在中等的 window 和 top-k 变化下稳定（原文附录 G，表 A.8），因此这些发现不是单一配置的产物。

静态上下文增强。 文件级上下文是最一致有效的策略，在所有设置下为 Go、Julia 和 Rust 达成最佳结果（例如 Claude：Go 上 34.14% TPR、52.63% Cov；Julia 上 23.98% TPR、34.83% Cov；Rust 上 21.16% TPR、18.93% Cov）。然而在 Ruby 上，文件级上下文急剧降低 IR（从 85.63% 到 53.19%），尽管改进了 TPR 和覆盖率——这是跨所有三个被评估模型的系统性权衡（IR 下降 21–32%），特定于 Ruby 重 DSL、富含元编程的生态。Go 和 PHP 在同一设置下对前两个模型显示可忽略的 IR 变化（±2%），尽管 GPT-OSS 在 Go 上显示更大的 IR 增益（+8.5%）。Julia 的 IR 变化跨所有三个模型同样很小（≤2%）。基于 LSP 的增强镜像开发者工作流，但收益是有选择性的；模型并不一致地利用细粒度依赖追踪，且过度解析的上下文可能变得嘈杂。

关键结论。 文件级上下文是最一致有效的增强，而基于检索和 LSP 的途径产生有选择性、语言依赖的增益。更丰富的上下文可能降低 IR，凸显测试有效性与调用可靠性之间的权衡。总体而言，即使最佳模型在标准设置下跨所有语言至多达成约 27% TPR，确认 XRepoTest 是一个有挑战的基准。关键模型比较的统计显著性通过 bootstrap 重采样和 McNemar 检验确认（原文附录 H）。

5.3 失败模式分析

为分析失败模式，我们收集测试执行日志，并通过精炼和人工检查应用系统性分类。这产生五类：语法与编译、API 幻觉、类型系统与内存、逻辑与断言，以及测试设计与 Mock，捕捉跨（i）可运行脚手架、（ii）有效 API 使用、（iii）类型/内存约束和（iv）行为正确性的反复出现的崩溃点。完整定义和分类见原文附录 J.2。

结果分析。 表 4 报告按总样本归一化的失败模式，因此每列求和为 100%。API 幻觉是多数语言中的主导失败。在 Rust 中，上下文增强减少了幻觉但提高了逻辑与断言失败，表明更丰富的上下文帮助模型产出可运行测试，但语义正确性仍是瓶颈。在 Julia 中，API 幻觉在上下文下略有增加（47.90% → 50.10%），表明额外上下文并不能可靠地为 Julia API 使用提供根基，语义正确性仍是主要挑战。Ruby 的幻觉率大体不受上下文影响。Go 显示更分布式的画像：上下文减少了幻觉和编译错误，但逻辑与断言上升，确认一旦脚手架问题解决，oracle 正确性是主要限制因素。PHP 是一个例外——上下文减少了编译失败但增加了 API 幻觉，表明更丰富的上下文引入了更多误用框架特定 API 的机会。

总体而言，改进 API 根基和 oracle 质量是更好测试成功的关键。更多示例和讨论见原文附录 J。

5.4 Agentic 与迭代修复评估

为超越单轮提示，我们额外在同一协议（TPR、Cov、IR）下评估 agentic 和执行在环的修复工作流。鉴于 agentic 评估成本更高，我们用分层子集抽样，每仓库最多五个简单和五个困难焦点函数。

Agentic 执行。 一个有完整仓库访问权（导航、编译、执行、迭代修复）的无头 Claude Code agent，相比被动单轮生成，把 TPR 在全部五种语言上提升 1.2–2.6 倍（表 5）。关键的是，多指标设计暴露了仅看通过率会漏掉的东西：在 PHP 上，agent 把 TPR 提升 11.5%，但覆盖率下降 33.3%、IR 下降 71.3%，因为通过的测试演练的是更容易的辅助或公共 API 而非分配的焦点函数；在 Julia 上，agent 达到 100% IR 但覆盖率更低，因为多重分派选择了非焦点的方法重载。仅按通过率聚合会高估 agent 能力；IR 和覆盖率共同暴露了这些失败模式。

迭代修复。 一个把编译器和执行反馈喂回模型的单轮修复循环（GPT-OSS-120B），把 TPR 改进 9–26% 而 IR 几乎不变，确认 XRepoTest 在一个协议下支持迭代修复工作流。

IR vs TPR 分歧。 跨整个基准，9.7% 的 TPR 通过套件仍然在 IR 上失败（Rust 28.3%、Ruby 19.2%、Go/PHP 0.6–0.7%、Julia 6.1%）；人工检查确认这些套件调用的是被 mock/stub 的或无关的公共 API 而非焦点方法——这是 IR 捕捉到 TPR 漏掉的失败的直接证据。完整的逐语言结果、修复表和一个 Julia 分派失配案例研究见原文附录 F。

表 5：分层子集上 agentic（无头 Claude Code）vs 被动单轮评估

Agentic 执行一致提升 TPR，而 Cov 和 IR 可能大幅下降（如 PHP），揭示仅看通过率评估所掩盖的失败。

6 结论

本工作中，我们提出 XRepoTest，一个用于单元测试生成的多语言仓库级基准和评估框架，强调真实开发设置、受控上下文增强和基于执行的指标。覆盖多种编程语言、多样领域和容器化环境，XRepoTest 能系统分析现代 LLM 如何在不同语言下生成、调用和验证测试。我们对 14 个最先进 LLM 的评估揭示了源于语言特定约束、领域复杂性和生成测试中语义问题的重大挑战。为更好评估行为有效性，我们提出了新颖的调用率（IR）指标，补充测试通过率（TPR）和覆盖率等标准指标。我们进一步探索了上下文增强策略对测试生成的影响。虽然静态文件级上下文在若干语言上提供最可靠的增益，更复杂的增强（如基于 LSP 或检索的上下文）产生有选择性、语言依赖的收益。总之，这些发现把 XRepoTest 定位为一个有挑战、信息丰富的基准，用于推进真实仓库上下文中可扩展、稳健的多语言单元测试生成，同时凸显了自适应上下文选择、语言感知增强，以及为测试 oracle 构造更强语义推理等未来工作的有前景方向。

7 局限

本工作中，为可比性，我们用标准化提示格式和固定解码配置评估所有模型。替代的提示策略、解码方案或工具增强设置可能产生不同的绝对性能，并可能更好地利用特定模型。类似地，基于检索的增强对检索器设计选择（如分块策略、索引粒度和相关性评分）敏感，我们基于检索的上下文结果不一定反映最优调优的检索流水线。此外，XRepoTest 聚焦五种研究不足但有影响的语言（Rust、Go、Julia、PHP 和 Ruby）和一组精选的真实仓库。虽然这一范围使有意义的多语言、仓库级评估成为可能，结果可能无法直接泛化到其他编程语言、应用领域或测试框架。为部分解决这一点，我们发布了一个可扩展的容器化评估流水线，设计来便利未来向额外语言、仓库和测试生态的扩展。

致谢

本论文部分受 MOSAICO 项目（Management, Orchestration and Supervision of AI-agent COmmunities for reliable AI in software engineering）支持，该项目获得欧盟 Horizon Research and Innovation Action 资助（Grant Agreement No. 101189664）。

署名与许可：原文 XRepoTest: Benchmarking Multilingual Repository-Level Unit Test Generation for Large Language Models，作者 Dung Le Quang、Dong Cao Van、Nam Le Hai、Linh Ngo Van、Anh M. T. Bui（Hanoi University of Science and Technology）、Phuong T. Nguyen（University of L'Aquila），arXiv:2608.25939v2。原文以 CC BY 4.0 许可发布。中文全译由智测团队完成，译文同样以 CC BY 4.0 发布；图 1、图 2 及原文图 3 版权归原作者。原文地址：https://arxiv.org/abs/2608.25939 。译文中省略了参考文献列表、文内引注编号，以及仅存于原文附录（A–K）的完整逐模型数据表；正文主结果表（表 2）只节选 Rust 与 Go 两行作示例，完整 14 模型 × 5 语言 × 5 上下文设置的数据请以英文原文为准。模型名、工具名、基准名、指标名保留英文。如译文与原文有出入，以英文原文为准。