《Test-Driven Development - A Practical Guide》读书笔记 - 第1章

第1章：测试驱动开发

1.         人人都知道测试有益，但是为什么还有那么多系统没有经过良好的测试？原因如下：“测试不够详尽”、“测试是代码结束后才进行的”、“测试经常不是由编写代码的程序员进行的”、“测试编写人员编写测试时所依赖的是文档或其他东西而不是代码本身”、“测试不是自动进行的”、“在一个地方改正了错误却又在别的地方引入了错误”。

2.         测试驱动开发解决了所有这些问题，还附带解决了一些其他问题：“测试由程序员完成，保证了其可测试性，而且是自动的”、“全面彻底的测试覆盖意味着任何bug一出现，就立即能发现它的位置”、“详尽的测试集和程序一起发布，从而使将来对程序的修改和扩展更加容易”。

3.         设计会更加简单，测试本身就有助于对系统进行描述，而且每天的build都是健壮的。

4.         程序员能在工作的时候得到正反馈（positive feedback），这就是工作进展顺利的实际证明。

5.         测试驱动开发（Test-Driven Development，TDD）是一种开发方式：需要委会一套详尽的程序员测试集；除非存在相关测试，否则不编写任何产品代码；首先编写测试；由测试来决定需要编写怎么的代码。

6.         使用程序员测试（Programmer Test）来测试类所表现的行为是否是正确的。它和单元测试（Unit Test）但是编写它们的目的不同。编写程序员测试是为了定义代码工作的含义。理论上讲，采用测试驱动开发就意味着你有一套详尽的测试集（Test Suite）。因为除非存在其目的是为了让产品代码通过的测试，否则就不存在任何产品代码，因为不存在任何不是为了响应测试而存在的代码。

7.         极限编程的原则之一就是在与之相关的一套测试还没有被编写出来之前，不要编写任何功能代码。这样保证了系统中的一切都必须是可测试的（testable），这是可以赋予你自信和勇气的安全网（safety net）的一部分。这些所有的代码都是经过测试的自信可以赋予你执行重构和集成（integration）的勇气。

8.         先编写少量测试，随后编写足够使测试通过的代码，然后再多编写一些测试，接着再编写一些代码，再编写测试，再编写代码，等等，以此类推。

9.         由测试来决定哪个你需要编写哪些代码，编写最简单的但又能工作的代码（do the simplest thing that could possibly work）。以一种小的增量方式来工作，有时候虽然少得可怜，但是非常重要的，甚至会有意想不到的好处和副产品。

10.      尽管编写测试代码，无需操心准备一份“To Do List”。需要增加一个类或者一个方法什么的，编译器会告诉你。随着编写更多的测试，需要对一开始编写的最简单的代码进行归纳（generalizing）和重构（refactoring）。

11.      编写测试时，需要消除在我们使测试通过的时候儿引入的重复（duplication）或其他一些有味儿的代码（code that smells）。

12.      一个最简单的例子：中文版P6-P8页。

13.      每次进行小的修改后一定需要重新编译并通过，这给予我们足够进行下去的信心和保证。要使用计算机的反馈来跟踪我们下一步的工作。我们如果要创建一个类、方法、变量什么的，系统会告诉我们的。

14.      从事XP的人与用户描述（user story）打交道，这个是敏捷模型。只要模型有助于我们开发软件，那么我们就去做。

15.      有些开发人员不从测试角度思考问题，对于这种可视化的思想者（visual thinker），使用可视化建模技术；对于有测试头脑的人，我们使用TDD。

16.     使用 TDD 来快速验证模型是否有效，这符合敏捷建模（ AM ）中“用代码来证明”（ Prove it With Code ）实践方法。 XP 和 TDD 紧密相关，相互支持。