有效测试的 50 条建议 - 单元测试(28~30)

纯粹的单元测试把一个组件和它可能调用的所有外部组件分离开,这里提到的单元测试并不是纯粹的单元测试,不需要分离外部组件,所以产生了一些集成测试的效果。

第 28 条:用结构化的开发方法来支持有效的单元测试

一个大的系统通常采用模块化的方法编写代码,将功能分成若干层次,系统实现的简单示例可以包含下面几个层次:

我们应该根据系统的详细需求,把用例或者其他文档作为单元测试工作的指南。系统每个层次增删的代码,这是在设计阶段确定的,为了保证每个层次都正确实现了他们负责的需求部分,每个受影响的层次中的组件都必须通过针对他们的单元测试。在每个涉及的层的单元测试程序中,证明该层提供了满足需求的必要功能。除了测试符合需求的情况,还应该测试错误情况(也称为异常)来确认组件能够优雅的处理错误的输入和其他异常条件。

第 29 条:在实现之前或者与实现同时开发单元测试

前提:大部分需求文档必须在开发之前准备好。
在实现软件之前开发单元测试的好处:

开发人员必须重视基于接口的方法实现组件,优秀的软件工程做法是围绕接口,而不是围绕组件内部的机理来设计软件。组件的接口可以用存根模块来代替,所以他还有助于单元测试的开发。存根是指通过接口调用的每个方法 (函数) 可以实现成知识一个返回预定义的、硬编码的结果,而没有真正的内部逻辑。
在实际工作中,总是在第一步就创建单元测试是困难多。在某些情况下,单元测试的开发和软件实现必须(也是可以接受的)同时进行。这种情况下,还是应该尽量预先定义完整的接口,并且针对接口中确定的部分开发单元测试。剩余部分和相关的单元测试可以随着开发工作逐渐完善。

第 30 条:使单元测试的执行成为生成过程的一部分

单元测试代码在编写之后不再定期的更新、维护和执行是相当普遍的现象,要求每次生成必须执行相应的单元测试,就避免了这些问题,但这种做法也是要付出代价的,比如在项目进度非常紧张时,纠正错误的压力就非常大,但用很短的时间更新单元测试,就能在随后的调试和查找缺陷中节省很多时间。
许多开发项目使用了自动生成来定期生成系统的正式版本,新版本包含了代码的最新改动。把单元测试加到生成过程中,使得生成过程增加了另一种质量保证机制。
单元测试的主要问题是不一致性,许多软件工程师没有采用统一的和结构化的方法进行单元测试。建议采用标准化工作方法,选择或创建一种单元测试框架。

本文章援引《Effective software testing》一书内容,为个人读后笔记,特此声明


↙↙↙阅读原文可查看相关链接,并与作者交流