编程语言与软件工程2024arxiv.org
Meta 使用大语言模型自动改进单元测试
Automated Unit Test Improvement Using Large Language Models at Meta
进阶 · 约 30 分钟读完前置知识：单元测试基础、大语言模型基础、代码覆盖率指标
导读
这篇 Meta 的论文介绍 TestGen-LLM，一个用大语言模型自动改进已有单元测试的工具。在 Instagram Reels 和 Stories 代码上的评估显示：75% 的生成测试用例能正确构建，57% 能稳定通过，25% 提升了覆盖率，其中约四分之一的建议最终被工程师采纳。
HN 关注点：LLM 自动生成测试的实际效果与可靠性，讨论焦点是这些数字是否足够好，以及自动生成的测试是否会固化代码中的 bug。
HN 评论精选
这几条评论里：质疑 3 亲历 1
质疑LLM 生成的测试可能固化 bug，应隔离存放并保持怀疑
75% 的 TestGen-LLM 测试用例构建正确，57% 稳定通过，25% 提升覆盖率。我对 LLM 生成测试的疑虑是：它们很可能“认可”已有的错误行为，在测试覆盖率本来就很低的代码库里尤其如此。手写新测试的好处之一是有人能判断到底是系统有问题还是测试有问题。至少应该把这些测试隔离在专门的目录里，以便用适当的怀疑态度对待。
tivert查看英文原文
> 75% of TestGen-LLM's test cases built correctly, 57% passed reliably, and 25% increased coverage. The problem I have with LLM generated tests is that it seems highly likely that they'd "ratify" buggy behavior, and I'd think that'd be especially likely if the code-base already had low test coverage. One of the nice things about writing new tests by hand is you've got someone who can judge if it's the system being stupid or if it's the test. At a minimum they should be segregated in a special test folder, so they can be treated with an appropriate level of suspicion.
亲历以覆盖率为 KPI 会催生无意义的测试，亲历教训
我之前任职的一家大型保险公司，管理层设定了整个代码库 80% 测试覆盖率的目标。于是大家开始为 Java DTO 的 getter 和 setter 写愚蠢的单元测试来凑指标，当然也不允许修改 Sonar 的覆盖率统计规则。作为年轻开发者，这教会我：只盯着 KPI 可能催生与初衷相悖的行为。几个精心设计的 E2E 测试场景对软件质量的影响可能反而更好。
hubraumhugo查看英文原文
At a large insurance company I worked for, management set a target of 80% test coverage across our entire codebase. So people started writing stupid unit tests for getters and setters in Java DTOs to reach the goal. Of course devs also weren't allowed to change the coverage measuring rules in Sonar. As a young dev, it taught me that focusing only on KPIs can sometimes drive behaviors that don't align with the intended goals. A few well-thought out E2E test scenarios would probably have had a better impact on the software quality.
质疑质疑论文给出的效果数字并不理想
在 Instagram Reels 和 Stories 产品上的评估中，75% 的 TestGen-LLM 测试用例构建正确，57% 稳定通过，25% 提升覆盖率。这看起来不怎么样？
newzisforsukas查看英文原文
> In an evaluation on Reels and Stories products for Instagram, 75% of TestGen-LLM's test cases built correctly, 57% passed reliably, and 25% increased coverage. That doesn't seem great?
质疑质疑论文缺乏可复现性，追问是否开源
我得承认这很有意思，一篇 Meta 员工写的 12 页论文，用来推广面向开发者的 AI，甚至用上了桑基图。我可能是错的，但如果以这种方式发表，难道不应该提供可复现所需的信息吗？这不是阴谋论，只是我没有 Meta 那样的数据来训练模型。所以，也许他们开源了什么？
bilekas查看英文原文
I'll admit its interesting, a 12 page paper by Meta employees to promote AI for developers. Even brought out the Sankey diagram. I'm probably wrong but if its published in this way, shouldn't the information be given to reproduce it ? Edit: This is not tinfoil hat, I just don't have the kind of data that meta has to learn from. So, maybe they released something ?
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2024Hacker News 讨论帖301 分 · 188 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选