第2章 个人技术和流程
2.1 单元测试
软件是由多人合作完成的，不同人员的工作相互有依赖关系。例如，一个人写的模块被其他人写得模块调用。软件的很多错误都来源于程序员对模块功能的误解、疏忽或不了解模块的变化。如何能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？单元测试就是一个很有效的解决方法。
单元测试应该在最基本的功能/参数上验证程序的正确性。
单元测试必须由最熟悉代码的人（程序的作者）来写。
单元测试过后，机器状态保持不变。
单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。
单元测试应该产生可重复、一致的结果。
独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
单元测试应该覆盖所有代码路径。
单元测试应该集成到自动测试的框架中。How？
单元测试必须和产品代码一起保存和维护。
2.1.3 回归测试
针对一个Bug Fix，我们也要做Regression Test。目的是：
1.验证新的代码的确改正了缺陷
2.同时要验证新的代码有没有破坏模块现有的功能，有没有Regression
个人感受部分：
1、过去怎么做：
以前在写程序时都是直接敲代码，没有先构建基本思路，让后再细分，解决每一个小的分块。以前都是完成代码项目后，运行在着错误bug，没有进行单元调试，导致错误百出。
2、结合书中，这样的坏处：
不讲任务细分到一个小板块会导致困难重重，时间浪费，不进行单元测试会导致错误许多，项目的质量下降，bug难查等
3、解决办法：
将巨大的任务板块化，解决每一个小的问题。进行单元化测试，修复每个单元的bug，在项目汇总的时候会减少不少麻烦。