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