有效测试的 50 条建议 - 单元测试（28~30）

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

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

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

• 数据库抽象
• 域对象
• 业务处理
• 用户界面

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

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

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

• 单元测试强迫软件的开发方式能够满足每一条需求。
• 开发人员的精力集中在解决某一专门的问题上，而不是开发一个也能满足需求的、巨大的解决方案。
• 可以推测开发人员的实现目标（对照需求陈述的内容）

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

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

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

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