单元测试框架的开发流程
简介
单元测试可以更快地发现代码中的错误，因此各个编程语言都拥有了专门的单元测试框架。本文按照一般的开发流程来讨论单元测试框架，即需求分析、设计实现，应用模型等等，希望可以提取单元测试的共性，为理解不同的测试框架提供支持。
需求分析
从单元测试的机制可以发现一部分隐藏需求，总结如下：
- 独立测试：针对一个软件单元。
- 用例组织：可以选择执行测试。
- 自动执行测试用例：可以重复执行。
- 自动验证测试结果：可以帮助排错过程。
满足以上几点，单元测试甚至可以作为一个可以执行的规格说明和文档。
设计实现
现有的单元测试一般由一个软件框架支持，提供对需求的基本支持，以gtest为例：
- 独立测试：与待测单元单独形成一个执行文件，并在适当的时候完成测试场景的设置与拆除。
- 用例组织：提供三级结构：环境、用例、用例对象
- 自动执行：可以通过环境变量、命令行等等输入测试用例的名字，支持正则表达式。
- 自动验证：提供一些原语，例如EXPECT_EQ等。这些原语会提供一些信息，例如是否成功，在那一行上失败，额外的信息提示等等。
测试框架的序列图如上，其中Fixture是需要用户定制的测试场景，最简单的情况就是场景中只有待测系统SUT，而且不需要设置，例如测试一个函数时的情况。
应用
软件框架只有定制以后，才能发挥作用。对于不同应用场景的定制，仍然遵循一般的软件原则，例如模块化，DRY（不要重复自己），开闭原则（对修改封闭，对扩展开放）等等。需要强调的是：
- 简单测试：测试本身的代码必须简单，例如无分支语句，否则还要写测试代码的测试。
- 帮助排错：测试失败之后，要提供帮助排错的信息；测试目的尽可能简单，使得失败原因一目了然。
- 测试场景：
- 设置独立的测试场景，可能会有性能问题，需要考虑一些针对性的方案。
- 为了解决待测系统的依赖性，需要设置测试替身，同时也能完成一些对象交互的验证工作。
- 可测试性设计：方便设置测试替身，尽可能减少不可测代码。
结语
开发单元测试框架仍然需要遵守一般的开发规范，因此从框架规范中整理出框架背后的需求、设计和实现的一些内容，对于理解和执行单元测试，可以提供额外的帮助。
参照
[1] Gerard Meszaros，XUnit test patterns : refactoring test code，Pearson Education, Inc， 2007
[3] Gtest, http://www.cnblogs.com/coderzh/archive/2009/04/06/1426755.html
