编程与软件工程blog.kentcdodds.com
写测试：不要太多，以集成测试为主
Write tests. Not too many. Mostly integration
2017 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Kent C. Dodds 的这篇文章讨论测试策略：应该写测试，但不要盲目追求数量或 100% 覆盖率，并让测试更多偏向集成测试，以更接近真实使用方式、减少过度 mock。它主张按项目情况权衡测试组合，而不是把某一种测试比例当成教条。
为什么经久不衰：它用一句易记的口号挑战测试教条，提醒团队以信心和真实使用方式而非覆盖率数字来衡量测试，因此多年后仍能引发共鸣。
HN 评论精选
反对把集成测试当解药：减少 mock 应先改进代码结构，单元测试仍更易维护。
为什么非要集成测试？作者说写更多集成测试的关键是少 mock，这我同意；但不必靠集成测试来摆脱 mock，而应写出更好的代码。通常一个单元测试需要多个 mock，说明我太执着于当前代码结构，应该拆分函数或重构问题。接受代码有问题后，往往代码更清晰、测试更容易。单元测试更快、更容易写和修，需求变化时也可以删掉重写；最糟的是有人因为旧测试花了三小时就舍不得删，硬要回收利用。
hinkley查看英文原文
Good lord. Why integration tests? I think the biggest thing you can do to write more integration tests is to just stop mocking so much stuff. Okay. The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language. So they try to write E2E tests which work for about 5 or 6 quarters and then fall apart like a cheap bookcase. If you can find a new job before then, you never have to learn to write good tests! I agree with the author that the trick is to stop using mocks all the time, but you don’t have to write integration tests to get rid of mocks. You have to write better code. Usually if I have a unit test with more than one mock it’s bcause I’m too invested in the current shape of the code and I need to cleave the function in two, or change the structure of he question asked (eg, remake two methods into two other methods). Almost always when I accept that the code is wrong, I end up with clearer code and easier tests. Unit tests run faster, are written faster, and not only can they be fixed faster, they can be deleted and rewritten if the requirements change. The most painful thing to watch by far is someone spending hours trying to recycle an old test because they spent 3 hours on it last time and they’ll be damned if they’re going to just delete it now.
测试金字塔仍有道理：不同层级测试的运行时机和数量应分层。
为什么要重新发明一套已经有效的策略？多写快的单元测试，适量写较快的集成测试，少写较慢的系统集成测试。测试金字塔是有效的；作者文中也提到它，却又忽略了它的重点。多写单元测试是因为可以在提交前或组件构建中快速运行；如果集成测试又多又有趣，就做不到这一点。集成测试更适合作为功能分支合并的门禁，系统集成测试则用于更稳定的上游分支或每日构建。
throwaway5752查看英文原文
Why does everyone rethink a working strategy. Write lots of unit tests that are fast. Write a good amount of integration tests that are relatively fast. Write fewer system integration tests that are slower. The testing pyramid works. He even talks about it in this post, and then ignores the point of it. You write lots of unit tests because you can run them inline pre-commit or in a component build. If you integration tests are numerous and interesting enough, that won't work. They are better suited to gating feature branch merges. System integration (the actual name for "end to end") take longer and usually gate progressively more stable branches upstream, or nightlies depending on where you are.
测试的价值在于消除改动恐惧；需求变更时测试应随之更新。
我的经验法则：测试是为了驱散恐惧。每当我担心改代码会弄坏东西，就一直写测试直到这种不安消失，每次都有效。关于文章：“重构时几乎不应改测试”没错，但大多数时候开发者改的是需求导致的预期行为，这不是重构。需求变了，测试当然该变；我只是澄清那句话只适用于重构。
hathawsh查看英文原文
My rule of thumb: tests cast away fear. Whenever I get that sinking feeling that I'll break things when I change the code, I write tests until my doubts disappear. It works every time. In response to the article: it's true that "you should very rarely have to change tests when you refactor code", however, most of the time, most coders are changing the expected behavior of the code due to changed or added requirements, which is not refactoring. Tests should change when the requirements change, of course. I am not contradicting the article, only clarifying that the quoted statement does not apply outside refactoring. (Refactoring is improving the design or performance of code without changing its required behavior.)
在生命安全等高风险领域，追求 100% 覆盖率有实际价值，不能一概反对。
作者说强制 100% 覆盖率是坏主意，希望管理者别误解。我曾参与一个项目，团队一直说“100% 覆盖率没用”，但那些人只读了这类文章，没想清楚适用场景。我的经验是没有通用的测试数量法则，够安全就好。我做的软件会在病人生命体征达到医生设定标准时触发警报；我很庆幸达到了 100% 覆盖率，因为从 60% 到 100% 之间有许多小边界情况，一旦导致死亡我无法安睡。如果被明令禁止写测试，我会周末或请假来补。
gravypod查看英文原文
> I’ve heard managers and teams mandating 100% code coverage for applications. That’s a really bad idea I hope many managers and programmers out there don't take this the wrong way. I've been an engineer on a project that was attempting to get 100% code coverage on a piece of software I was writing. I heard constant remarks during this period that were similar to "You don't need 100% code coverage, it doesn't do anything!" These engineers who I was working with had only read articles like this and didn't stop to think about what the article was trying to say. From my experience there is no safe rule of thumb for for how many tests should be implemented for a project. There should be just enough to feel safe (as hathawsh has said). If you're recommending to engineers on your team to stop implementing tests when they say "I'm at 60% coverage and it'll take ~2 days to get to 100%" I'd really hope you take the time to understand why they want 100% coverage. The software I was working on when my coworkers started telling me to stop writing tests was code designed to trigger alarms when patient's vital signs met certain criteria set by doctors. I am very thankful that I did hit 100% coverage because between 60% and 100% there were many small edge cases that, had they caused a death, I wouldn't have been able to sleep well. Had they said I was explicitly disallowed from working on the tests I would have come in on a weekend (or taking a PTO) and implemented them then. It's our ethical responsibility to know when and where paranoia is worth the marginal time penalty.
历次讨论
同类还值得读
开源应用架构
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编辑精选