单元测试框架的开发流程

标签：

单元测试可以更快地发现代码中的错误，因此各个编程语言都拥有了专门的单元测试框架。本文按照一般的开发流程来讨论单元测试框架，即需求分析、设计实现，应用模型等等，希望可以提取单元测试的共性，为理解不同的测试框架提供支持。

 从单元测试的机制可以发现一部分隐藏需求，总结如下：

• 独立测试：针对一个软件单元。 
• 用例组织：可以选择执行测试。 
• 自动执行测试用例：可以重复执行。 
• 自动验证测试结果：可以帮助排错过程。 

满足以上几点，单元测试甚至可以作为一个可以执行的规格说明和文档。

设计实现

现有的单元测试一般由一个软件框架支持，提供对需求的基本支持，以gtest为例：

• 独立测试：与待测单元单独形成一个执行文件，并在适当的时候完成测试场景的设置与拆除。
• 用例组织：提供三级结构：环境、用例、用例对象
• 自动执行：可以通过环境变量、命令行等等输入测试用例的名字，支持正则表达式。
• 自动验证：提供一些原语，例如EXPECT_EQ等。这些原语会提供一些信息，例如是否成功，在那一行上失败，额外的信息提示等等。

测试框架的序列图如上，其中Fixture是需要用户定制的测试场景，最简单的情况就是场景中只有待测系统SUT，而且不需要设置，例如测试一个函数时的情况。

应用

软件框架只有定制以后，才能发挥作用。对于不同应用场景的定制，仍然遵循一般的软件原则，例如模块化，DRY（不要重复自己），开闭原则（对修改封闭，对扩展开放）等等。需要强调的是：

• 简单测试：测试本身的代码必须简单，例如无分支语句，否则还要写测试代码的测试。
• 帮助排错：测试失败之后，要提供帮助排错的信息；测试目的尽可能简单，使得失败原因一目了然。
• 测试场景：
  • 　　设置独立的测试场景，可能会有性能问题，需要考虑一些针对性的方案。
  • 　　为了解决待测系统的依赖性，需要设置测试替身，同时也能完成一些对象交互的验证工作。
• 可测试性设计：方便设置测试替身，尽可能减少不可测代码。

结语

开发单元测试框架仍然需要遵守一般的开发规范，因此从框架规范中整理出框架背后的需求、设计和实现的一些内容，对于理解和执行单元测试，可以提供额外的帮助。

[3] Gtest, http://www.cnblogs.com/coderzh/archive/2009/04/06/1426755.html

单元测试框架的开发流程

标签：

原文地址：http://www.cnblogs.com/liuyunfeng/p/4903446.html