2008 年，我为 Windows 7 任务栏写了一个扩展插件，最后的应用程序非常小，只有几页代码。完成后，我接到指示，要为这个应用程序写单元测试，这么做只是为了能让经理检查打分。我拒绝了，因为这个项目实在太小了，根本不需要单元测试。而且，为了添加这些愚蠢的测试把应用程序拆成几个部分，意味着使本来已经通过了测试并准备发布的应用程序变得不稳定。
随着这次沟通逐渐无法进行，经理告诉了我一些话，即所谓的“测试驱动开发”，这时，我下决心要结束这场谈话，因为这是我第一次听到这样不合理的说辞：
当测试全部通过，你就完成了任务。
我遇见的每一个 TDD（Test Driven Development）宣传者都会一字一句地重复上面这句话。
测试什么时候写？
当时的我已经有了 20 多年的软件开发经验，我第一次意识到明显的缺陷所在，编码前就写测试需要记住一点：在与敌人的接触中，没有任何战争计划能够幸存。我工作过的大部分地方都认为软件计划是在浪费时间，他们最多也就是走走流程。
在微软，我好几次因为在软件开发中做了周全的规划而受到惩罚，特别是在写威胁模型时。但是，我总是从需求和功能规范开始规划工作，我拒绝了一些潜在客户，他们不愿意在编码前花时间做软件设计。
但是，即使是最周全的计划也会在编码实现后出现非预期的紧急事件，即便在若干小时内不会出现，也会在数天内出现。客户们的设计总是比他们认为的更加模糊不清，即使是我竭尽全力，也会有一开始想不到的事情发生。
所以，如果采用 TDD 架构，我就得不断地查看测试，审核所有测试项，确保它们满足我在项目里的新发现。而如果在工作结束时，或者快要结束时编写测试，测试项就会包含编码时所有的新发现。所以，这些都比在编码完成后写测试合理得多。
以下是我所看到的 TDD 流程：
编写 TDD 测试
开始编码
发现非预期的事件
重写测试
继续实现
返回步骤 3 重复、重复、重复……
（实际上，要多于 150 条测试）所有的测试都通过
发送到 QA 专区
假设，QA 部门因为 TDD 而没有被全部解雇。注意上面第四项，在大型项目中，重写测试可能要出现几十次，而每次重新检查 TDD 的测试项都是 100% 浪费时间。
传统方式更好
开始编码
发现非预期事件并修复
编码完成，编写测试并运行
修复 Bug
发送到 QA 专区
这种方法，我在有了发现之后才编写测试，因此，测试只针对最终的设计而编写，只在以下情况发生时重新审核测试：
QA 阶段发现 bug
添加新的功能
发布后发现新的 bug
问 题
这里存在的问题是 TDD 假设开发者自己写测试程序，这很不合理。我见过很多开发者认为项目非常稳固，但其他人却能在一分钟内就攻破它，这是为什么？
这是因为开发人员在设计时产生的盲点也同样会出现在测试中。
有谁会写一个比 Yes-No 消息框更复杂的功能，却又不运行它呢？在编码实现之前就编写测试，并不会解决这个问题。不管是在编码前写测试还是编码后写，总有些情况是开发人员预想不到的，这些情况倒不一定是“边缘情况”。每个人的工作都需要其他人根据需求和功能规范进行黑盒测试。
结 论
很多开发者可能有这样的想法：在 TDD 中重新审查测试所浪费的时间会带来更多收入，项目周期也会增加 20% 到 50%，这会让收入增加 20% 到 50%。但是，我认为这很不道德。坦率地说，这也十分无聊。
阅读任何有关 TDD 的宣传材料，它们都会归结到测试本身的争论，没有人会反对它，它也从不谈及在编码之前写测试的理由是什么。
