单元测试

9.1 TDD三定律

• 在编写不能通过的单元测试前，不可编写生产代码
• 只可编写刚好无法通过的单元测试，不能编译也不算通过
• 只可编写刚好足以通过当前失败测试的生产代码

9.2 保持测试的整洁

测试代码和生产代码一样重要。他需要被思考，设计和照料

9.3 整洁的测试

测试的要素：整洁性
** 9.3.1 面向特定领域的测试语言 **
面对特定领域的语言。不要直接使用程序员提供的对系统进行操作的API，而是打造一套包装这些API的函数与工具代码
** 9.3.2 双重标准 **
有些事在生产环境中不能够去做，而在测试环境中做却完全没有问题。

9.4 每个测试一个断言

9.5 F.I.R.S.T

F:Fast,测试足够快能够快速运行
I：Independency，测试应该相互独立，彼此没有联系
R：Repeatable，可以重复通过
S：Self-Validating，自足验证
T：Timely，及时

第十章 类

10.1 类的组织
类应该由一组变量列表开始，如果有公共静态变量，应该先出现，然后是私有静态变量，以及私有实体变量，很少会有公共变量。
公共函数应该跟在变量列表之后。我们喜欢将某个公共函数调用的私有工具函数紧随在该公共函数后面。
封装
我们喜欢保持变量和工具函数的私有性，但并不执着于此。放松封装总是下策。
10.2 类应该短小
类的大小的衡量，通过权责responsibility来判断 。
类的名称应该描述其权责，命名是判断类的长度第一个手段，如果无法精确命名一个类，或者类名过长，很含混，该类越可能含有过多的权责。
10.2.1 单一职责原则
系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并于少数其他类一起协同达成期望的系统行为。
10.2.2 内聚
类应该有少量实体变量。类中的每个方法都应该操作一个或多个变量。通常而言，方法操作的变量越多，就越黏聚在类上。如果一个类中的每个变量被每个方法所使用，则该类具有最大的内聚性。
10.2.3 保持内聚性会得到许多短小的类
当类丧失了内聚性，就拆分它。
10.3 为了修改而组织
对于大多数的系统，修改将一直持续。每处修改都让我们冒着系统其他部分不能如预期般工作的风险。在整洁的环境中，我们对类加以组织，以降低修改的风险。
隔离修改
需求会改变，所以代码也会改变。我们学习到，具体类包含实现细节，而抽象类只呈现概念。依赖于具体实现的客户类，当细节改变时，就会有风险。我们可以借助与接口和抽象类来隔离这些细节带来的影响。

第十一章 系统

11.1 如何建造一个城市
在较高的抽象层级---系统层级上保持代码整洁。
11.2 将系统的构造和使用分开
软件系统在起始过程中和起始过程之后的运行时逻辑分离开，在起始过程中构建应用对象，也会存在相互缠结的依赖关系。

=====