第二章讲的是个人技术和流程。绝大多数软件是由多人合作完成的。单元测试能够让自己负责的模块功能定义更加明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证。

  创建一个单元测试函数的主要步骤是：

1.设置数据

2.使用被测试类型的功能

3.比较实际结果和预期的结果

  在写技术模块规格说明书的时候，要越详细越好，最好各项要求都可以表示为一个单元测试用例。单元测试也并不是件容易的事，单元测试应该准确、快速地保证程序基本模块的正确性。首先单元测试应该在最基本的功能/参数上验证程序的正确性。单元测试应该测试程序中最基本的单元——如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成）。从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法及每一个参数。其次，单元测试必须由最熟悉代码等的人（程序的作者）来写。单元测试后，机器状态应保持不变，这样就可以不断进行单元测试。单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）快才能保证效率。因为一个软件中有几十个模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。单元测试应该产生可重复、一致的结果。单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。程序中的各个模块都是相互依赖，否则他们就不会出现在一个程序中。一般情况下，单元测试中的模块可以直接应用其他的模块，并期待其他的模块能返回正确的结果。如果其他模块很不稳定，或者其他模块运行比较费时（如进行网络操作），而且对于本模块的正确性并不起关键的作用，这是可以人为的构造数据，以保证单元测试的独立性。单元测试应该覆盖所有代码途径，包括错误处理路径。为了保证代码覆盖率，单元测试必须测试公开的和私有的函数/方法。单元测试应该集成到自动测试的框架中。单元测试必须和产品代码一起保存和维护。在单元测试的基础上，我们就能建立一个回归测试，回归测试能在一个新的构建中出了问题，这个模块就能从正常的状态退化到不正常工作状态。针对一个Bug Fix，我们要做Regression Test，目的是：1.验证新的代码的确改正了缺陷 2.同时要验证新的代码有没有破坏模块的现有功能，有没有Regression。所以，对于回归测试中的回归，可以理解为回归到以前不正常的状态。回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有的回归测试，以保证尽早发现问题。单元测试是回归测试的基础。

《构建之法》第二次