编程与软件工程martinfowler.com
TDD 已死吗？（2014）
Is TDD Dead? (2014)
2014 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Martin Fowler 网站上关于 2014 年那场著名辩论「Is TDD Dead?」的专题页面：Kent Beck、David Heinemeier Hansson（DHH）与 Fowler 本人围绕测试驱动开发是否已经走到尽头、mock 是否让测试变脆、以及测试先行是否妨害设计探索展开的系列对话（含视频与文字记录）。它并非一篇单一文章，而是一组讨论的入口，后续还引出 Gary Bernhardt 等人的回应。
为什么经久不衰：它把「测试先行」从教条还原成可讨论的工程取舍：十多年过去，关于单元边界、mock 与可测试性、以及快速交付与设计质量的张力，仍是每个团队要面对的问题。
HN 评论精选
TDD 被咨询业扭曲了；应按「清晰边界的单元」和「对外行为」来写测试，而不是按类和方法。
我认为这个话题上最好的演讲是 Ian Cooper 的「TDD, Where did it all go wrong?」。几点补充：TDD 和 Scrum 一样被「敏捷咨询产业」带偏了，回到 Kent Beck 最初的原则其实是相当合理的实践；人们说「单元测试」时，unit 并不是指常见的「一个类」，而是软件中边界清晰的一块，可以是一整个微服务，也可以是单体里自洽的一部分；关键在于「什么触发你写测试」——过度热情的测试者会给类里每个新公有方法写测试，结果测的是实现细节，因为大多数类只在一个单元内部被使用；用行为驱动的方式决定该测什么最合理：只有跨边界的人需要的行为才需要测试，否则测试是多余甚至有害的。因此好的触发规则是「每个单元对外期望行为一个测试，加上每修一个 bug 一个测试」，后者来自经验，标出单元里棘手的部分并锁住它们。
VHRanger查看英文原文
The best talk on this topic, IMO is Ian Cooper: "TDD, Where did it all go wrong?" https://www.youtube.com/watch?v=EZ05e7EMOLM Couple of notes: - TDD, much like scrum, got corrupted by the "Agile Consulting Industry". Sticking to the original principles as laid out by Kent Beck results in fairly sane practices. - When people talk about "unit tests", a unit doesn't refer to the common pattern of "a single class". A unit is a piece of the software with a clear boundary. It might be a whole microservice, or a chunk of a monolith that is internally consistent. - What triggers writing a test is what matters. Overzealous testers test for each new public method in a class. This leads to testing on implementation details of the actual unit, because most classes are only consumed within a single unit. - Behavior driven testing makes most sense to decide what needs tests. If it's required behavior to the people across the boundary, it needs a test. Otherwise, tests may be extraneous or even harmful. - As such, a good trigger rule is "one test per desired external behavior of the unit, plus one test per bug fixed". The test for each bugfix comes from experience -- they delineate tricky parts of your unit and enforce workign code around them.
TDD 更适合规格稳定的库代码，而非快速变化的业务代码，混淆两者会带来麻烦。
我在读 Lakos 的《Large Scale C++》，他谈到两类代码：一是应用代码——变化快、规格不清，需要快速开发周期去「发现」客户想要什么，首要任务是尽快、尽可能可靠地取悦客户；二是库代码——变化慢、规格严格，开发周期长而保守，首要任务是支撑应用开发者。TDD 大概适用于第二类，对第一类则不太适用。而且我们都梦想当库开发者（代码和规格稳定、能活几十年），可惜大多数人其实是应用开发者，代码寿命并不长。认清自己代码的寿命和团队的内在目标（快速粗糙的应用风格，还是缓慢谨慎的库风格）很重要。混用两种风格会出问题：用库风格写应用，规格会在脚下变化，一切都得按新客户的喜好重写；用应用风格写库，你自己都不够稳定，没人愿意用你的库。
dragontamer查看英文原文
I've been reading "Large Scale C++" by Lakos. There are two kinds of code Lakos writes about: 1. Application code -- Fast changing, poorly specified code. You need to have a rapid development cycle, "discovering" what the customer wants. Your #1 job is pleasing the customer, as quickly, and as reliably, as possible. 2. Library code -- Slow changing, highly specified code. You have a long, conservative development cycle. Your #1 job is supporting application programmers. TDD probably works for #2, less so for #1. Furthermore, we all dream of being library developers (that our code and specifications are stable, and that our code can last decades). Alas, most of us are Application developers, and the lifespan of our code isn't really that long. Recognizing the lifespan of your code, as well as the innate goals of your team (quick and dirty application style, or slow and careful library style) is important. ------------ Mixing up the styles causes issues. If you write library-style code for an application, the specification will change under your feet and everything needs to be rewritten to the new whims of your new customers. If you write application-style code for a library, you yourself won't be "stable enough" to support your peers, and no one will want to use your library.
复杂领域里设计本身是迭代的，测试先行会阻碍探索性编码。
在复杂领域里，TDD（至少在面向对象设计中）意味着你没法先探索性地试写，看看该有哪些对象、做哪些决定——毕竟你得在类存在之前就为它写好测试。等你写完测试、开始填代码，才发现需要重构时，已经有一大堆测试要跟着改。在我看来这非常低效，而且前提是作者能在动手写代码之前就把类的层次结构表达清楚。以我的经验，类的设计是高度迭代的，连方法名、有哪些方法都在变；在写代码之前先写测试，会严重阻碍表达解决方案的思路。这不是在批评单元测试，而是在批评 TDD。
jpz查看英文原文
TDD for a complex domain generally means (at least in an OO design) you cannot do exploratory coding over what objects you have and what decisions you will make. After all, you have to write the tests for the classes, before the classes exist. When you do so, then start to fill in the code, and then realise you need to refactor, you have a heap of tests you need to refactor. It always appeared to me highly inefficient and predicated on an assumption that the author can express his class heirarchies well ahead of the coding. In my experience, the class design is highly iterative, even the names of methods, what methods you have, etc - to have to write the tests before you've written the code just creates a huge amount of impediments to the flow of expressing a solution. This is not a criticism of unit testing - but of TDD.
不必教条地测试先行：边写边测同样能获得安全感和探索自由。
TDD 没有死，但希望那种把僵化、教条式、近乎宗教的软件开发方法论强加给有创造力的个人的做法能死掉。TDD 和极限编程、敏捷一样，有好有坏；听听这些人怎么说，然后挑对你有用的。对我来说，TDD 是同时写代码和测试，而不是测试先行：一旦写出刚好能用的代码，我就写个测试看它是否真的工作，然后扩充这个测试，并在重构时再加几个。这样我既保留了不受测试先行束缚的探索式编程的好处，又获得了「改动没弄坏东西」的安全感。随着代码库增长，你对质量的信心也跟着增长，而不是反过来（一堆通过的测试）。而且文件保存即运行的快速测试套件很上瘾，我无法想象再回到靠 F5 的开发方式。
phpnode查看英文原文
TDD is not dead, but hopefully the practise of foisting rigid, prescriptive, quasi-religious software development methodologies on creative individuals is. TDD, like all of these things - eXtreme Programming, agile, has good points and bad. Listen to what these people have to say, and then take what works best for you. To me, TDD is about writing my code and my tests at the same time, not test first. As soon as I write just enough code to do something, I'll write a test to see if it actually works. I'll then expand on that test and perhaps add a few more as I refactor that piece of code. This means I still get the benefits of exploratory programming, unconstrained by test first, but I also get the security of knowing that my changes didn't break anything. It feels very natural to develop this way, as the code base grows, your confidence in its quality grows with it, rather than the inverse (lots of passing tests). Also a fast test suite which runs on file save is addictive, I cannot imagine returning to F5 Driven Development now.
历次讨论
同类还值得读
开源应用架构
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编辑精选