关于测试驱动开发

看了一本有关测试驱动开发的书，一些摘录和感想：

TDD的最终目标：整洁可用的代码 Clean code that works

测试驱动开发的对立面：体系结构驱动的开发（Architecture-driven Development）
TDD首先解决可用的问题，然后考虑整洁，ADD正好相反。

TDD的工作流程：
（1）写一个测试程序
（2）让测试程序编译通过
（3）运行测试程序，发现不能通过
（4）让测试程序可以运行
（5）消除重复设计，优化设计结构
个人理解：
（1）为了能方便地写测试程序，往往需要先写出被测程序函数的Signature
（2）第4步的含义应该是“修改被测程序，以便符合测试程序的断言要求（Assertion）”
（3）第5步也很重要，说明TDD并不否认良好设计的重要性，只是工序上的问题，也就是说，
TDD认为：应该先让代码能工作，再让代码更整洁。

依赖关系与重复设计
依赖关系是各种规模的软件开发中的关键问题。
例子：使用某个数据库厂商的SQL方言，导致系统依赖该数据库产品，无法移植到其他数据库系统。

如果依赖关系方面有问题，表现就是重复设计。
重复设计就是重复的逻辑设计，也就是相同的代码在多个地方出现。

消除重复设计就是消除依赖关系。

To-do List工作方法：
列出需要完成的任务，做完一个划掉一个。
避免过多的头绪影响对当前问题的全神贯注。

三角法（Triangulation）
三角法是让测试运行的办法之一，让测试利落运行的另外两个方法是：伪实现和显明实现。
三角法是TDD的最保守的实现方法。
仅当Test Case达到2个或更多，并且第2个Case需要更一般化的解决方案时，才对代码实施一般化（泛化/抽象？）。
核心思想是：设计时考虑需要支持哪些变化，如果没有看到新的需求，就不要修改现有代码。

重构
TDD对于重构有一个“时时做，一次做一点”的思想。
“为明天编码、为今天设计”（教科书上说“编码为今天，设计为明天”）
“不为代码的将来考虑，你的代码反而更有可能适应将来的需要”
个人理解：
如果一次做太多，可能导致过度设计；
如果老不做，到了被迫做的时候又会畏难。

TDD的局限：
不要指望用TDD代替其他类型的测试：性能测试、安全性测试、压力测试、可用性测试。
UI测试不太适用。
TDD的原则是先写测试代码再写实现代码，所以不要指望在一个已经编码很多的项目中途采用TDD。