编程与软件工程rbcs-us.com
为什么大多数单元测试是浪费
Why Most Unit Testing is Waste [pdf]
2014 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是软件顾问 James Coplien 的争议性文章《为什么大多数单元测试是浪费》，主张大部分单元测试成本高、收益低，建议只保留高价值的测试并定期清理长期未失败的测试。文章在 Hacker News 上多次引发关于单元测试、TDD 和 mock 框架价值的热烈争论。
为什么经久不衰：它挑战了“测试越多越好”的行业教条，无论你同意与否，都能促使你重新审视自己团队的测试策略，因此多年反复被翻出讨论。
HN 评论精选
坚决反对丢弃旧测试：测试是防回归的救生艇，且写测试过程本身就能发现 bug
论文里说“扔掉一年没失败过的测试”？绝对不行。我们的单元测试保证了多年后有人改代码时，不太可能破坏现有行为。扔掉单元测试就像说‘这船开了多年没沉过，把救生艇扔了吧’。而且单元测试不只是防回归——每个测试夹具都帮我们找到过至少一个 bug，在测试运行器里调试比在运行时排查容易得多。
peterclary查看英文原文
From the paper: "Throw away tests that haven’t failed in a year." Hell, no. Our unit tests provide reassurance that when somebody revisits a component N years from now, and makes a change, they are significantly less likely to break the existing behaviour, even subtly. Throwing away unit tests is like saying "This ship has been sailing for years and has never sunk - let's throw away the lifeboats!" Now, yes - somebody could erroneously change the test condition to make it pass, although hopefully that kind of change would be spotted by even a cursory code review. You can say the same thing about developers who carelessly suppress compiler warnings without understanding what they're telling them. However, the support is there in case I, or another developer, make a mistake. FWIW, catching future mistakes is definitely not the only thing for which we use Unit Tests. The problem domain is hard, and for every test fixture we've written we've found at least one bug. Catching and debugging these bugs from the unit test runner is a lot easier than spotting and debugging these kinds of issues at runtime.
问题根源常是设计差而非测试少，行业缺乏对‘何时该认真测试’的讨论
好的设计比好的测试套件长期价值更大。很多开发者花大量时间为糟糕设计写测试，原型代码带着 bug 直接上生产，答案总是‘加更多测试’而不是‘更好的设计’。团队早该重构或重写时却继续在烂代码上堆砌。什么时候该做彻底测试、项目何时从原型转向生产质量，这个话题讨论得太少了。
programminggeek查看英文原文
A good design is going to provide more value over time than a good test suite. A lot of developers spend a lot of time writing tests for terrible design on prototype codebases. Those prototypes eventually are thrown into production full of bugs and the answer tends towards "more tests!" instead of "better design!" Most developers just keep building on top of the same codebase until it is a total mess, long after the team has learned a bunch and should refactor or throw away the code and build something designed for production use. There is really not enough discussion about when he right time to do thorough testing and when a project transitions from prototype to production quality. I realize things like software design, planning, and thoughtfulness are heresy in the agile world of 2 week sprints, but most of these things are our own fault due to a lack of planning and craftsmanship. Complain all you want, but in general it's our own fault.
测试的真正价值在于让开发者集中注意力，而非文章所批评的回归防护
‘我当年为可测试性写代码，但几乎不写单元测试，代码质量却很有名。’原因在于：任何能在开发过程中集中注意力的东西都能提升质量。单元测试可以扮演这个角色，但那意味着它的价值在 Coplien 没有描述的地方。
michaelfeathers查看英文原文
"When I was programming on a daily basis, I did make code for testability purposes but I hardly did write any unit tests. However I was renowned for my code quality and my nearly bug free software. I like to investigate WHY did this work for me?" Here's why: anything that focuses attention during development improves quality. Unit tests can be that thing but that means that their value is in a place that Cope is not describing. See: http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html
不写单元测试的后果已被验证：无文档、不敢重构、维护地狱
好，那我们别写单元测试试试——其实已经试过了，结果很清楚：动态语言里类型错误只能靠系统级测试兜底；模块没有行为文档；没人敢重构，代码腐烂；bug 由昂贵的人力而非代码来抓；系统测试挂了没人知道去哪查；没人敢复用旧模块，导致重复造轮子。单元测试不能证明代码正确，但能建设性地证明它不正确。
avip查看英文原文
Ok let's stop writing UT and see what happens. Wait... we've already tried that, and we know the result pretty well: 1. In dynamic languages, simple type mismatches, wrong variable names etc. are now caught in "top level system level test". Yes these are bugs that should have been caught by a compiler had we had one. 2. There's no documentation as to how something should work, or what functionality a module is trying to express. 3. No one dares to refactor anything ==> Code rottens ==> maintenance hell. 4. Bugs are caught by costly human beings (often used to execute "system level tests") instead of pieces of code. 5. When something does break in those "top level system tests", no one has a clue where to look, as all the building blocks of our system are now considered equally broken. 6. It's scary to reuse existing modules, as no one knows if they work or not, outside the scope of the specific system with which they were previously tested. Hence re-invention, code duplication, and yet another maintenance hell. Did I fail to mention something? UT cannot assert the correctness of your code. But it will constructively assert its incorrectness.
历次讨论
同类还值得读
开源应用架构
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编辑精选