代码整洁之道
简介：
本书是编程大师“Bob 大叔”40余年编程生涯的心得体会的总结，讲解要成为真正专业的程序员需要具备什么样的态度，需要遵循什么样的原则，需要采取什么样的行动。作者以自己以及身边的同事走过的弯路、犯过的错误为例，意在为后来者引路，助其职业生涯迈上更高台阶。
本书适合所有程序员阅读，也可供所有想成为具备职业素养的职场人士参考。
第五章 测试驱动开发（TDD）
如果连所有代码是否都可以正常运行都不知道，还算什么专业人士？如果每次修改代码后没有测试，如何能够知道所有代码可以正常运行？如果缺乏极高覆盖率的自动化单元测试，如何能够做到每次修改代码后都对代码进行测试？如果不采用TDD，如何能够获得极高覆盖率的自动化单元测试？
5.2 TDD的三项法则
（1）在编好失败单元测试之前，不要写任何产品代码。
（2）只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。
（3）产品代码恰好能够让当前失败的单元测试通过即可，不要多写。
5.3 TDD的优势
确定性：
如果将TDD作为一项行业纪律，那么每天要写上几十个测试，每周要写上成百上千个测试，每年写上成千上万个测试。任何时刻，代码有任何修改，都必须运行手头有的全部测试。
任何时刻，一旦修改了工程的任何部分，只需再次运行全部的单元测试即可。如果单元测试全部通过，我差不多就可以确信我的修改没有破坏任何东西。“差不多少确信”是有多少把握？我相当有把握，足以交付了！
降低缺陷注入率：
有不少报告和研究[3]称TDD能够显著降低缺陷。从IBM到微软，从Sabre到Symantec，一家又一家公司，一个又一个团队，经历过缺陷下降为原来的1/2、1/5甚至1/10的过程。这些数字不能不让专业人士动容。
给开发人员以修改优化工程的勇气：
看到糟糕代码时，你为什么不修改呢？看到混乱的函数时，你的第一反应是：“真是一团糟，这个函数需要整理。”你的第二反应是：“我不会去碰它！”为什么？因为你知道，如果去动它，就要冒破坏它的风险；而如果你破坏了它，那么它就缠上你了。
但是如果你能确信自己的整理工作没有破坏任何东西，那又会是怎样一种情况呢？如果你拥有我刚才提到的那种把握，会怎样呢？如果你只需点击一个按钮，然后90秒内便可以确信自己的修改没有破坏任何东西，只是让代码变得更好了，那么又会是怎样的一种情况呢？这是TDD最强大之处。拥有一套值得信赖的测试，便可完全打消对修改代码的全部恐惧。当看见糟糕的代码时，就可以放手整理。代码会变得具有可塑性，你可以放心打磨出简单而满意的结果。
当程序员不再惧怕整理代码时，他们便会动手整理！整洁的代码更易于理解，更易于修改，也更易于扩展。代码更简洁了，缺陷也更少了。整个代码库也会随之稳步改善，杜绝业界常见的放任代码劣化而视若不见的状况。
单元测试就是文档：
遵循TDD三项法则的话，所编写的每个单元测试都是一个示例，用代码描述系统的用法。如果遵循三项法则，那么对于系统中的每个对象，单元测试都可以清楚描述对象的各种创建方法。对于系统中的每个函数，单元测试可以清楚描述函数的各种有意义的调用方式。对于需要知道的任何用法，单元测试都会提供详尽的描述。
单元测试即是文档。它们描述了系统设计的最底层设计细节。它们清晰准确，以读者能够理解的语言写成，并且形式规整可以运行。它们是最好的底层文档。
利于设计：
如果不先写测试，就有可能出现各个函数耦合在一起最终变成无法测试的一大团的问题。如果后面再写测试，你也许能够测试整个大块的输入和输出，但是很难测试单个函数。因此，遵循三项法则并且测试先行，便能够产生一种驱动力，促使你做出松耦合的设计。
总结：使用测试驱动开发是专业人士的选择；
它是一项能够提升代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。对TDD的各项尝试表明，不使用TDD就说明你可能还不够专业。
当然，在某些场合照这三项法则去做会显得不切实际或不合适。这种情况很少，但确实存在。如果遵循某项法则会弊大于利，专业的开发人员就当然不会选用它。
