测试优先或测试驱动开发（TDD）是你在编写程序前先编写测试的软件开发方法。你编写程序来通过测试，扩展测试或增加测试然后再扩展程序功能来通过这些测试。你先花费时间建立一系列的测试，然后你可以在每次程序修改时自动运行测试。这是为了确保每时每刻程序都能够运行并通过测试。你周期性地重构你的程序来提高它的结构并让它易读易改。

外界宣称测试优先式开发提高了测试覆盖率，并且在不改变现有功能基础上，能够更简单的改变程序。测试的作用就像文档一样，你有了一个关于程序应该做什么的详细又抽象的描述。

几个月前，我谨慎的决定体验测试优先式开发。作为一个退休的程序员，我编写的是我私人的项目，而不是一个有文档说明的客户端。所以我在此所说的话或许仅仅适用于没有严格程序文档的情况。

起初，我发现这个方法（测试驱动开发）很有用。但我开始实现一个 GUI 时，编写测试很困难，而且我认为编写测试所花费的时间并不值得。然后，我并没有完全（或许是不纯粹地）按照TDD的要求去实现，所以我没有对所有东西做自动化测试，有时在编写测试前就实现了一些东西。

但是，我并不是因为编写 GUI 自动化测试的（众所周知的）困难而放弃 TDD 。我放弃是因为我认为它在编程中鼓励保守主义，它鼓励你设计能通过测试的决策，而不是符合用户的正确决策，它使你专注于细节而不是架构，并且它并不能适用于主要的一类程序问题——那些由意外的数据引起的问题。

• 因为你想确保你总是可以通过大多数的测试，当你改变并扩展程序时你倾向于思考这一点。你因此不情愿做出会导致大量测试失败的大范围的变更。从心理上讲，你变得保守并避免破坏大量测试。
• 往往对程序设计做测试比其他更容易。有时，最棒的设计是很难测试的，所以你不情愿采取这种方法，因为你知道你将花费大量时间设计并编写测试（对于我来说真的是一件无聊的事）。
• 对于我来说最严重的问题是 TDD 鼓励专注于整理细节来通过测试，而不是把程序看做一个整体。我每次开始编程时只有有限的上机时间，并且需要花费时间审视并思考程序整体。我认为这带来优雅又优秀的结构化程序。但是 TDD 让你深入程序不同部分的细节，很少能够退后一步审视大局。
• 根据我的经验，很多程序出现失败是因为处理的数据并不是程序所期待的。编写能够精确反映出你将要处理的坏数据的「坏数据」测试很困难，因为你需要成为一个领域专家并理解数据。「纯粹主义者」解决这点，当然，那就是你设计了数据校验检查，所以你不需要处理坏数据。但是现实中通常很难定义什么是「正确的数据」，并且有时你不得不处理你得到的数据而不是你预期的数据。

所以，我回到原点开始先写代码，然后写测试。我继续在有意义的地方做自动化测试，但在我能清楚读懂代码并理解它做什么的时候，我不会花费大量荒谬的时间编写测试。思考优先比测试优先是一条更好的路。

附言。我很确定 TDD 纯粹主义者会说我做的不正确，所以没有真正从 TDD 受益。或许他们是对的。但是我还没有找到狂热者能够说服我。

放弃测试优先式开发（TDD），首发于文章 - 伯乐在线。