首页 > 代码库 > 读构建之法 第二章:个人技术和流程

读构建之法 第二章:个人技术和流程

绝大部分软件都是由多人合作完成的,大家的工作相互有依赖关系。某人负责的模块的功能被其他人调用,但如何让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的、量化的保证???单元测试就是一个很有效的解决方案。

创建单元测试函数的主要步骤是:

1.设置数据(一个假象的正确的E-mail地址)

2.使用被测试类型的功能(用E-mail地址来创建一个User类的实体)

3.比较实际结果和预期的结果(Assert.IsTrue(target!=null)

创建完就可以运行单元测试了,同时可以看看代码覆盖报告,代码百分百地都被覆盖了。

 

怎样才算一个好的单元测试呢单元测试应该准确、快速地保证程序基本模块的正确性

验证单元测试好坏的一系列标准:

1.单元测试应该在最基本的功能、参数上验证程序的正确性;

2.单元测试必须由最熟悉代码的人(程序的作者)来写;最好是在设计的时候就写好单元测试,这样单元测试就能体现API的语义,保障语义的准确性。

3.单元测试过后,机器状态保持不变;这样就能不断地运行单元测试

4.单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟);快才能保证效率

5.单元测试应该产生可重复、一致的结果;

6.独立性——单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性;

7.单元测试应该覆盖所有代码路径,包括错误处理路径;(要注意:100%的代码覆盖率并不等同于100%的正确性

8.单元测试应该集成到自动测试的框架中;把单元测试自动化,这样每个人都能随时随地运行单元测试。

9.单元测试必须和产品代码一起保存和维护;

在单元测试的基础上,建立关于这一模块的回归测试(Regression Test)

针对一个Bug Fix,我们也要做Regression Test。目的是1.验证新的代码的确改正了缺陷 2.同时要验证新的代码有没有破坏模块的现有功能,有没有Regression

回归测试中的回归可以将其理解为“回归到以前不正常的状态”

回归测试最好要自动化,这样就可以对于每一个构建快速运行所有回归测试,以保证尽早发现问题。

VSTS提供了方便的效能分析工具,让我们能很快地找到程序的效能瓶颈,从而能有的放矢,改进程序。

效能分析可以选择两种分析方法:

1.抽样(Sampling)优点:不需改动程序,运行较快,可以很快找到瓶颈,缺点:不能得出精确的数据,也不能准确表示代码中的调用关系树

2.代码注入(Instrumentation)缺点是程序的运行时间会大大加长,还会产生很大的数据文件,相应的增加了数据分析的时间,同时注入的代码也影响了程序真实的运行情况。

一般的做法是先用抽样的方法找到效能瓶颈所在,然后对待定的模块用代码注入的方法进行详细分析。

看个人项目耗时对比记录表,显然,从学生到职业程序员,并不是更加没完没了的写程序——花在写代码上的时间反而少了许多。

实践是理论的基础和验证标准

实践最简单的项目:WC,根据书上项目要求,实现一个统计程序

如何保证质量——回归测试

如何为这个程序做有效的测试,有以下几种方法,自动化程序由低到高。

1.手动测试,手工比较

2.要做到不断地测试,可以把WC的主要功能封装成一个类,然后测试程序员调用这一个类的主要函数,得出结果并与标准作比较。

3.更进一步,比较测试的输出和标注结果

4.再进一步,把自动构建脚本和构建验证测试结合起来。记录出现的bug。

我看完认为第二章主要讲的是 在设计的时候就写好单元测试,保证程序基本模块的正确性;在单元测试的基础上,建立模块的回归测试,保证之前所有已经发现并修复的bug的确得到了修复,并没有在最后一个版本中复发,才能保证尽早发现问题。还有对程序的效能分析,提高效能,优化程序。

 

读构建之法 第二章:个人技术和流程