读书笔记二

构建之法阅读笔记02

2017.2.1

第二章 个人技术和里程

2.1单元测试

  软件是有多人合作完成的，不同的人员的工作相互有依赖关系。例如，一个人写的模块被其他人写的模块调用。软件的很多错误都来源于程序员对模块功能的误解，疏忽或不了解模块的变化，如何让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？单元测试就是一个很有效的解决方案。

1. 设置数据（一个假想的正确的E-mail地址）  2.使用被测试类型的功能（用E-mail地址来创建一个User类的实体）  3.比较实际结果和预期的结果（Assert.IsTrue(target != null);）现在可以运行单元测试了，同时可以看看代码覆盖报告（CodeCoverage Report），代码百分之百地都被覆盖了。当然这时候的代码还有很多情况没有处理，例如，还没有：处理空的字符串，长度为零的字符串，都是空格的串。
2. 好的单元测试的标准
   1. 单元测试应该在最基本的功能、参数上验证程序的正确性。
   2. 单元测试必须由最熟悉代码的人（程序作者）来写。
   3. 单元侧事故过后买机器状态保持不变，
   4. 单元测试要快
   5. 单元测试应该产生可重复，一致的结果，
   6. 独立性
   7. 单元测试应该覆盖所有的代码路径
   8. 单元测试应该继承到自动测试的框架中
   9. 单元测试必须和产品代码一起保存和维护。

个人感悟：

1. 我过去是怎么做的

过去是一次性写完了所有的代码。

1. 结合书中所讲，说明为什么不好

没有写软件单元测试，不知道程序的对错，可能程序出错后没有方法能够及时发现

1. 提出一个方法，避免再次掉入陷阱。

写程序的陈厚，每一个功能模块一定要定义清楚，并且写出单元测试来检测代码的正确性。