验证单元测试好坏的9条标准

近日,小何在移山公司实习了一段时间,所获颇丰。特别是对移山公司的单元测试水平感受很深。移山公司建立了一套验证单元测试好坏的标准,小何实习回来后,就迫不及待地把它分享给了大家。

移山公司的验证单元测试好坏的标准一共有9条,分别如下:

  • 单元测试应该在最低的功能/参数上验证程序的正确性

单元测试要测试的单元应该是程序中最基本的单元——如在C++/C

  • 单元测试必须由最熟悉代码的人(程序的作者)来写

要做好单元测试,执行人员就需要了解代码单元的目的、特点、架构和设计思路、实现的局限性。而最清楚这些的,就是作者。所以,没有比作者更适合进行单元测试的人选。

  • 单元测试过后,机器状态保持不变

机器状态保持不变的意思是说,让单元测试的环境始终保持一致。如果一次单元测试创建了临时的文件或目录,在单元测试完成后要删除这些目录;如果单元测试在数据库中创建或修改了记录,那么也许要删除这些记录,或者每一个单元测试使用一个新的数据库。这样做的目的是保证单元测试不受以前单元测试实例的干扰,可以让单元测试不断地运行。

  • 单元测试要快(一个测试运行时间是几秒钟,而不是几分钟)

快,才能保证效率。

一个软件中通常会有很多个基本单元(类),每个单元又有几个方法,如果单元测试花费时间太长,很难想像会给开发带来什么样的影响。

如果软件的模块设计遵循了高内聚低耦合的原则,模块具有很高的独立性,那么可以分类运行单元测试,比如如果只修改了“用户界面”的代码,就只需运行“用户界面”的单元测试。

  • 单元测试应该产生可重复,一致的结果

如果单元测试的结果是错的,那一定是程序出了问题,而且这个错误一定是可以重复的。

这也是所有测试类型都应遵循的标准。

  • 单元测试要保持独立性

单元测试的独立性,是指单元测试的运行/通过/失败不依赖于别的测试,可以人为地构造单元测试的数据,以保持单元测试的独立性。

虽然程序中的各个模块都是互相依赖的,一个模块的运行要引用其他的模块,但我们在进行单元测试的时候,要使用桩(Stub)或者模拟对象(Mock)来替代其他模块,以保证被测单元的测试不受干扰。

  • 单元测试必须覆盖所测单元的所有代码路径

单元测试应该覆盖所有代码路径,包括错误处理路径,为了保证单元测试的代码覆盖率,单元测试必须测试公开的和私有的函数/方法。

100%的代码覆盖率是单元测试的基本要求。

  • 单元测试应该集成到自动测试的框架中

单元测试自动化,将使得执行单元测试的花费大大地降低, 这样每个单元测试的错误就能及时发现并得到修改。

单元测试自动化和构建自动化、代码控制结合起来,是一套高效的代码实现的解决方案。

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

单元测试必须和代码一起进行版本维护,这主要是应对单元测试和构建持续频繁进行的情况。因为如果不是这样,代码和单元测试就可能会出现不一致,需要花时间来分析确认哪些是程序出现的错误,哪些是由于单元测试更新滞后造成的错误。这样就失去了单元测试的意义。

以上就是小何学习到的验证单元测试好坏的9条标准。

这正是:

单元测试基本类,保持独立可重复,

实现自动快测试,做好保存和维护。

参考文献:移山之道:VSTS软件开发指南,邹欣

作者简介:王小双,长期从事GJB5000推广、实施、评价、改进的工作,创建《软件工程之思》微信公众号,一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。

验证单元测试好坏的9条标准》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/3349.html