编程与软件工程pixelbeat.org
GNU coreutils 是如何测试的
How the GNU coreutils are tested
2018 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章由 Pádraig Brady 撰写，介绍 GNU coreutils（cat、ls、cp 等基础命令行工具）的测试体系：测试套件如何组织、测试用例如何编写与运行，以及维护这些看似简单的工具为何需要如此繁重的测试工作。适合想了解成熟开源项目工程实践的读者。
为什么经久不衰：它揭开了一个被所有人天天使用、却极少被审视的基础设施的内部质量保障机制，且这类“项目 X 如何测试”的一手总结稀少而耐读。
HN 评论精选
呼吁更多项目公开测试实践，并推荐 SQLite 的测试文档。
我们需要更多这种“项目 X 是怎么测试的”文章，继续来！这里还有一篇讲 SQLite 的：https://www.sqlite.org/testing.html
nathell查看英文原文
We need more of these „How project X is tested” articles. Keep them coming! Here’s one on SQLite: https://www.sqlite.org/testing.html
开源不等于高质量，但顶尖的软件工程流程多见于开源项目。
读完这页我想起一条推文。开源不等于质量好，但在我看来（也可能只是确认偏误），在极端情况下，最优秀的软件交付流程往往来自开源项目——当然我也能举 NASA 的项目来反驳自己。
CraigJPerry查看英文原文
I read this page and i'm reminded of this tweet: https://twitter.com/6thgrade4ever/status/1433519577892327424 It's not true that just because a product is open source, it will be of good quality. I don't have enough knowledge to say the following is true or that i'm not just suffering confirmation bias but it does appear to be true that at the extremes, the best quality software delivery processes are from open source projects. I would shoot holes in my own argument by pointing out specific projects from NASA.
测试应尽量前移到编译器和语言层面，降低对人的依赖。
我期待随着语言成熟，测试的易用性能改善。比如 Rust 允许把可运行代码放进函数文档里，避免文档与实现脱节。不过归根结底，最有效的还是把尽可能多的检查交给编译器/虚拟机去做——人（包括我自己）常常因为经验不足、疏忽或时间压力写得不够健壮，我说过无数次“回头再补测试”。
Decabytes查看英文原文
I'm looking forward to the improvements to the ergonomics of testing as programming languages mature. For example I really like how Rust has allowed the integration of runnable code into the docstrings of functions to combat documentation being out of date with the current iteration of the function. Ultimately though, I believe any amount of testing that can be pushed into the compiler/virtualmachine of the language is the most effective. I've learned that people (myself included) don't always code as robustly as they could (either through inexperience, negligence, time/market constraints etc). I can't count how many times I've told myself, I'll go back and write a test for this later.
GNU 工具逻辑复杂，因此连 cat 都需要重度测试。
你听过那句老话吗：“你要么把程序做得简单到显然没有 bug，要么做得复杂到看不出明显的 bug。”GNU 的程序属于后者，所以它们才要费这么大力气去测试 cat。
Sir_Cmpwn查看英文原文
Have you ever heard that old phrase "you can either make a program so simple it obviously has no bugs, or you can make a program so complex that it has no obvious bugs"? GNU programs are the latter. That's why they need to go to such lengths to test "cat".
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选