首页 > 代码库 > 《构建之法》第二次

《构建之法》第二次

  第二章讲的是个人技术和流程。绝大多数软件是由多人合作完成的。单元测试能够让自己负责的模块功能定义更加明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的、量化的保证。

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

1.设置数据

2.使用被测试类型的功能

3.比较实际结果和预期的结果

  在写技术模块规格说明书的时候,要越详细越好,最好各项要求都可以表示为一个单元测试用例。单元测试也并不是件容易的事,单元测试应该准确、快速地保证程序基本模块的正确性。首先单元测试应该在最基本的功能/参数上验证程序的正确性。单元测试应该测试程序中最基本的单元——如在C++/C#/Java中的类,在此基础上,可以测试一些系统中最基本的功能点(这些功能点由几个基本类组成)。从面向对象的设计原理出发,系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法及每一个参数。其次,单元测试必须由最熟悉代码等的人(程序的作者)来写。单元测试后,机器状态应保持不变,这样就可以不断进行单元测试。单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟)快才能保证效率。因为一个软件中有几十个模块(类),每个模块又有几个方法,基本上我们要求一个类的测试要在几秒钟内完成。单元测试应该产生可重复、一致的结果。单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性。程序中的各个模块都是相互依赖,否则他们就不会出现在一个程序中。一般情况下,单元测试中的模块可以直接应用其他的模块,并期待其他的模块能返回正确的结果。如果其他模块很不稳定,或者其他模块运行比较费时(如进行网络操作),而且对于本模块的正确性并不起关键的作用,这是可以人为的构造数据,以保证单元测试的独立性。单元测试应该覆盖所有代码途径,包括错误处理路径。为了保证代码覆盖率,单元测试必须测试公开的和私有的函数/方法。单元测试应该集成到自动测试的框架中。单元测试必须和产品代码一起保存和维护。在单元测试的基础上,我们就能建立一个回归测试,回归测试能在一个新的构建中出了问题,这个模块就能从正常的状态退化到不正常工作状态。针对一个Bug Fix,我们要做Regression Test,目的是:1.验证新的代码的确改正了缺陷 2.同时要验证新的代码有没有破坏模块的现有功能,有没有Regression。所以,对于回归测试中的回归,可以理解为回归到以前不正常的状态。回归测试最好要自动化,因为这样就可以对于每一个构建快速运行所有的回归测试,以保证尽早发现问题。单元测试是回归测试的基础。

《构建之法》第二次