论文技术总结：面向测试的编程（Test-Oriented Programming, TOP）

论文标题：Test-Oriented Programming: rethinking coding for the GenAI era（面向测试的编程：GenAI 时代的编程再思考）
作者：Jorge Melegati (INESC TEC, 波尔图大学)
会议：ICSE-Companion '26

1. 研究背景与问题定义 (Problem)

随着大语言模型（LLM）在生成代码方面的能力日益增强，现有的辅助编程工具（如 GitHub Copilot、多智能体系统或“氛围编程”vibe coding）虽然提高了代码生成的速度，但并未显著提升软件开发的抽象层级。

• 现有局限：开发者仍需直接检查、理解和修改生成的“生产代码”（Production Code）。这意味着开发者的工作重心仍然停留在传统编程语言的实现细节上。
• 核心挑战：自然语言存在歧义性，直接将其作为编程指令难以保证确定性；而 LLM 生成的代码缺乏确定性（Non-determinism），导致结果不可靠。
• 研究目标：提出一种新的编程范式，利用 GenAI 将开发者的工作重心从“编写生产代码”转移到“验证测试代码”，从而将自然语言规格说明直接转化为可运行的软件系统，实现更高阶的抽象。

2. 方法论：面向测试的编程 (Methodology: TOP)

作者提出了**面向测试的编程（Test-Oriented Programming, TOP）**范式。其核心思想是利用 LLM 完全自动化生成生产代码，而开发者仅负责基于自然语言规格说明来编写和验证测试代码。

核心流程

1. 输入：开发者提供自然语言规格说明（项目描述、依赖、目标）和验收测试描述。
2. 测试生成：LLM 根据规格说明生成测试代码（包括单元测试和验收测试）。
3. 人工验证：开发者审查并修正测试代码，以消除自然语言的歧义，确保测试逻辑正确。
4. 生产代码生成：LLM 根据通过验证的测试代码自动生成生产代码（Production Code）。
5. 迭代：如果生成的生产代码无法通过测试，系统会自动重试或提示开发者修改测试/结构，直到所有测试通过。

工具实现：Onion

为了验证 TOP 的可行性，作者开发了名为 Onion 的概念验证工具：

• 架构：基于 YAML 配置文件的命令行工具。
• 工作流：
  1. 读取 YAML 配置（包含项目描述和测试描述）。
  2. 生成系统结构文件（YAML，定义包、类、方法）。
  3. 生成测试文件（Python）。
  4. 开发者验证测试文件。
  5. 利用测试执行结果驱动 LLM 生成具体的类实现代码。
  6. 运行验收测试生成主程序文件。
• 模型对比：实验使用了两种不同类型的 LLM 进行对比：
  • GPT-4o-mini (OpenAI)：推理能力较强的模型。
  • Gemini 2.5-Flash (Google)：非推理型/快速模型。

3. 关键贡献 (Key Contributions)

1. 提出 TOP 范式：定义了一种新的软件开发生命周期，将“测试驱动开发（TDD）”与"GenAI"结合。与传统 TDD 不同，TOP 中测试代码和生产代码处于不同的抽象层级：测试代码由人类（或辅助工具）定义逻辑，生产代码完全由 AI 生成。
2. 概念验证工具 Onion：提供了一个基于 YAML 配置和 LLM 交互的完整工作流原型，展示了从自然语言到可运行系统的自动化路径。
3. 实证研究：通过构建一个 BibTeX 条目管理命令行工具，对比了不同 LLM 在 TOP 范式下的表现，揭示了当前技术的潜力与瓶颈。

4. 实验结果 (Results)

研究团队使用 Onion 工具成功生成了一个 BibTeX 管理工具，并在多次尝试中观察到了以下结果：

• 可行性验证：
  • 在所有尝试中，从未需要直接修改生产代码。生产代码的生成完全由测试代码驱动。
  • 主要失败原因集中在测试代码的不一致性上。一旦修正测试代码，生产代码即可正确生成。
• 模型差异：
  • GPT-4o-mini：生成的代码更短、注释更少。在 5 次尝试中，仅需 1 次修改测试代码。
  • Gemini 2.5-Flash：生成的代码更长、注释更多（表现出推理模型的冗长性）。在 5 次尝试中，多次需要添加注释来引导模型，且更多时候是因为辅助代码（如导入、测试执行）的问题导致失败。
• 开发者干预点：
  • 开发者主要工作在测试代码的验证与修正上。
  • 在某些情况下，模型无法生成通过测试的代码，迫使开发者检查测试逻辑本身是否存在问题。

5. 挑战与局限性 (Challenges)

尽管结果令人鼓舞，但作者指出了将 TOP 应用于实际复杂项目时面临的三大挑战：

1. 测试代码的验证负担：
   • 生成的测试代码量巨大（尤其是对于 Gemini 2.5-Flash 等模型），人工审查和验证这些代码对开发者来说是一个巨大的挑战。
   • 需求：需要开发自动化工具来辅助开发者验证测试代码的正确性。
2. LLM 生成的非确定性：
   • 即使是相同的模型和相同的输入，多次运行生成的代码（包括测试代码和生产代码）也存在显著差异。这种变异性使得结果难以复现和预测。
3. 模型间的代码风格差异：
   • 不同模型生成的代码在长度、注释量和风格上存在巨大差异（例如推理模型倾向于冗长），这增加了统一代码库维护的难度。

6. 意义与展望 (Significance)

• 抽象层级的提升：TOP 代表了软件工程中抽象层级的又一次飞跃，类似于从汇编语言到高级语言（如 C）的转变。它将开发者的角色从“代码编写者”转变为“规格说明与测试逻辑的验证者”。
• 人机协作新范式：确立了“人类负责定义‘做什么’（通过测试和规格），AI 负责实现‘怎么做’（生产代码）”的新型协作模式。
• 未来方向：虽然目前 Onion 仅适用于小型项目，但作者认为复杂系统可以通过模块化（如微服务架构）的方式，将每个模块作为独立的 Onion 项目来生成。未来的研究重点在于解决测试代码验证的自动化问题以及提高 LLM 生成的确定性。

总结：该论文通过提出 TOP 范式和 Onion 工具，有力地论证了在 GenAI 时代，通过“测试驱动”而非“代码驱动”来开发软件是可行的。这为未来软件开发的自动化和抽象化提供了新的理论框架和实践路径。