《构建之法》第二章 读书笔记

《构建之法》第二章 读书笔记

好的单元测试标准

  • 单元测试应该在最基本的功能/参数上验证程序的正确性,单元测试要测试API中的每一个方法及每一个参数。
  • 单元测试必须由最熟悉代码的人来写。
  • 单元测试过后,机器状态保持不变。
  • 单元测试要快,快到几秒钟。
  • 单元测试应该产生可重复、一致的结果。
  • 独立性。单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据以保证测试的独立性。
  • 单元测试应该覆盖所有的代码路径。同时注意100%的代码覆盖率不等同于100%的正确性。
  • 单元测试应该集成到自动测试的框架中。
  • 单元测试必须和产品代码一起保存和维护。

效能分析

效能分析有两种方法:

  • 抽样。抽样就是对程序运行状态进行随机采样,查看程序当前在运行哪个函数。抽样不需要改动程序,运行快,可以很快找到瓶颈,但是不能得出精确的数据,也不能准确地表示调用关系树。
  • 代码注入。代码注入就是将检测的代码加入到每一个函数中。这会大大增加程序的运行时间,还会产生很大的数据文件,也相应增加了数据分析的时间。同时注入的代码也会影响程序真实的运行情况。

两个软件设计原则

  • 单一职责原则。一个模块(类)应该只有一个导致他变化的原因,一个模块应该完全对某个功能负责。这样避免引入不必要的依赖,增加可移植性,减少错误发生的风险。
  • 开放-封闭原则。软件实体应该是可扩展的,同时应该是不可修改的。允许扩展指当应用的需求发生改变时,我们可以对模块进行扩展,从而改变模块的功能;不可修改指对模块功能进行扩展时,不必改变模块的本身。

感想

测试确实是一个软件产品交付之前必不可缺环节。之前的学习中,对程序的测试仅限于找bug,很少会针对各个功能进行系统、全面的测试,更不要说单元测试回归测试自动化测试这些专业的测试要求,也没有用过效能分析工具(实际上根本没太关心过效能)。以后要注意这方面的学习,稍大点的项目应该都用得上。

猜你喜欢

转载自www.cnblogs.com/thechosenone95/p/9879283.html