Testing Framework Migration with Large Language Models
本文通过一个由真实案例组成的精选数据集，评估了大语言模型（GPT-4o 和 Claude Sonnet 4）在将 Python 测试套件从 \texttt{unittest} 迁移到 \texttt{Pytest} 的自动化过程中的有效性，发现虽然大语言模型可以加速这一过程，但近半数生成的迁移方案均告失败，并且根据模型和提示策略的不同，表现出明显的行为差异。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你拥有一座巨大的、古老的图书馆，里面的书是用一种非常严格、正式的语言——unittest 编写的。它运行得非常完美，但它笨重、占用空间大，且难以阅读。图书馆的所有者想把所有东西都搬迁到一个新的、现代化的语言——Pytest 中，后者更精简、更易读，且拥有更好的功能。
然而，手动搬运成千上万本书是一场噩梦。这需要数年时间，而且人们会感到疲劳。因此，这篇论文的作者提出了一个非常聪明的问题：“我们能否雇佣一个超智能的 AI 机器人（大语言模型）来替我们完成搬运工作？”
以下是他们所做的工作以及他们的发现，用简单的语言解释如下：
实验：AI 搬运工
研究人员从一些著名的开源项目（例如 Web 服务器和数据分析背后的工具）中挑选了 40 个特定的“书籍”（测试用例）。他们要求两个最聪明的 AI 机器人——GPT-4o 和 Claude Sonnet 4——将这些书从旧语言翻译成新语言。
他们尝试了不同的提问方式：
- 零样本（Zero-shot）： 只说，“翻译这个。”
- 单样本（One-shot）： 说，“翻译这个，这里有一个我希望完成的方式的示例。”
- 思维链（Chain-of-Thought）： 说，“在翻译之前，请逐步思考。”
他们还尝试调高或调低机器人的“创造力旋钮”，以观察增加随机性是否有助于解决问题。
结果：喜忧参半
结果就像雇佣了一支速度极快但有时会掉落箱子的搬运队。
- 成功率： 在每 100 次翻译尝试中，AI 大约能正确完成 48 次。另外 52 次则出现了翻译损坏且无法运行的情况。
- “完美的”搬运： 当 AI 成功完成时，这些书的运行情况与预期完全一致。其“故事”（代码逻辑）没有改变，且“足迹”（代码覆盖范围）也保持不变。
- “损坏的”搬运： 失败通常是因为 AI 忽略了一个细微的细节。它可能忘记带上某个特定的工具（一个“fixture/固件”），或者它可能稍微改变了一个数字，导致数学计算无法对齐。
机器人的个性
这两个 AI 机器人有着截然不同的风格，就像两位不同的建筑师：
- Claude Sonnet 4（保守的翻修者）： 这个机器人非常谨慎。它喜欢保留旧建筑的结构。如果原始测试是一个“类”（class，一个大的容器），Claude 就会保留它作为一个类。它不想改变太多，但这有时意味着它保留了一些旧有的、笨重的部分。
- GPT-4o（现代主义者）： 这个机器人渴望现代化。它喜欢拆掉那些大的“类”容器，并将其重建为简单的、独立的函数。它更积极地使用新语言的功能，但如果它改变得太快、太多，有时也会导致错误。
令人惊讶的发现
- 创造力并无帮助： 研究人员原本认为，如果他们让 AI “更有创意”（通过调高温度系数），AI 可能会找到更好的解决方案。事实并非如此。增加随机性只会让同样的错误发生，或者产生相同错误的略微不同版本。
- 示例可能具有误导性： 当他们给 AI 一个如何操作的示例时（单样本），AI 有时会过于关注那个特定的示例。即使该示例并不适合新的“书”，它也会模仿该示例的风格，从而导致错误。
- 简单 vs. 复杂： AI 非常擅长简单的翻译（比如改变一个词）。但当翻译需要理解代码不同部分之间的复杂关系（例如，一个测试如何连接到数据库）时，AI 经常会迷失方向。
底线结论
论文得出结论，AI 是这项工作中的强大助手，但它还没准备好成为唯一的负责人。
如果你让 AI 来迁移你的测试，它可以正确且快速地完成大约一半的工作。然而，人类仍然需要检查另外一半的工作。AI 就像一个精通外语但有时会忽略文化背景或实现故事所需特定工具的快速翻译员。
简而言之： AI 可以加速从旧测试框架向新框架的迁移过程，但你不能只是收拾好行李就离开；在箱子到达时，你仍然需要检查它们，以确保没有任何东西损坏。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。