sersync过滤目录规则

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。