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