这听起来太绝对，但确实是这样。

事件起因

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的宣传材料，它们都会归结到测试本身的争论，没有人会反对它，它也从不谈及在编码之前写测试的理由是什么。

原文链接：https://hackernoon.com/test-driven-development-is-fundamentally-wrong-hor3z4d

创作场景

观点：测试驱动的开发从根本上是错误的