p-unit 简介
或许我们已经习惯了使用 JUnit 来写单元测试来保证代码质量(我也一直这么做),但可能经常碰到这样的问题:
1.程序多线程下正确性如何?
2.如何测试程序的性能?
3.当有多个方案可以选择时,技术上如何比较不同方案的性能?
对于问题 1,我们或许听天由命?或是凭借人工分析,或是根据用户反馈?很多软件单线程下的单元测试覆盖率相当高,从而保证了代码的健壮性。然而多线程测试时常被忽略,这并不代表多线程测试不重要,相反,修正一个用户报告的多线程 BUG 往往比单线程的要高出很多,因为测试案例经常不是 100% 可重现的。这更要求程序员在开发阶段充分的重视。目前多线程单元测试力度不够的一个重要原因是没有一个像 JUnit 那样易用的测试工具,另外重复写测试案例往往不被程序员接受。
对于问题 2,一个成熟的关心性能的产品往往有一个性能测试平台。这个测试平台应该关注的是测试业务逻辑本身,而无需关心如何运行测试案例。你是否为写这样的测试平台痛苦过?以及花费时间在产生一些直观的报表上面?
对于问题 3,我们往往写一个原型来比较不同产品之间的性能,如何比较执行速度和内存消耗?或是选择最适合你的虚拟机?
p-unit 就是这么一款开源的性能测试软件,它能帮助你很好的解决上述问题。p-unit 可以:
*多线程支持:同一个测试案例可以单线程执行,也可以多线程执行,测试案例开发者只需写一套测试案例。
*参数化测试案例:很多测试案例,需要测试同一功能在不同数量级上的性能表现。
*不同虚拟机性能测试:只需指定虚拟机路径,即可测试同一个测试案例在不同虚拟机上的表现,报表上可以非常直观显示性能差别。
*事件机制构架:punit 是基于事件机制构架的,如果用户想定制报表,只需实现事件响应器,并注册该响应器到 punit 核心即可。
多线程执行测试案例
在了解如何多线程执行测试案例之前,我们先了解一下如何利用 p-unit 单线程执行测试案例。不同于 JUnit, p-unit 测试用例无需继承任何测试类或是实现接口,即可执行 test 开始的方法。尽管 JUnit 4 中加入了注释(Annotation) 的特性,但测试方法前缀为 "test" 仍然是测试者们的首选。因此如果你的 JUnit 测试案例遵循的是 test 命名规则,那么 p-uni t可以兼容运行 JUnit 测试案例。
下面的代码清单 1 是一个最为普通的测试案例:
清单 1. 测试案例 1
清单 2. 单线程运行测试案例
清单 3. 单线程运行测试案例结果
是否和想象中的一样?下面我们来看如何多线程执行这个测试案例。或许从上面的例子你已经猜到了,在 main 函数还是只需一句代码,只用把 PUnitSoloRunner 换成 PUnitConcurrentRunner 即可!
清单 4. 多线程运行测试案例
清单 5. 多线程运行测试案例结果
是否和想象中的一样?默认情况 p-unit 启动 10 个线程来执行,要指定不同的线程数,只需将线程数做为参数传入 PUnitConcurrentRunner 即可。p-unit 甚至支持不同的测试案例有不同的线程数,这要求测试案例实现 p-unit 中定义的 Concurrent 接口,该接口的定义为:
清单 6. p-unit Concurrent 接口
该接口的意思,相信无需再多做解释了,返回该测试案例需要的线程数。
参数化测试案例
性能测试,不同于单元测试,经常要求测试不同数量级在同一个测试场景中的表现,JUnit 是一款非常优秀的单元测试工具,但没覆盖到这个方面。比如我们比较类库 Foo1 的方法 bar() 和类库 Foo2 的方法 bar() 哪个更符合自己的应用程序,我们需要测试该函数在应用程序可能的数量级的范围内的表现。有经验的开发者知道经常碰到在小数量级 A 更好大数量级 B 更好的局面,因此全面的测试对于代码的性能理解非常重要,能帮助开发者做出正确的决定。p-unit 支持将参数传给测试方法,测试案例需要实现 p-unit 的 parameterizable 接口,该接口的主要方法是返回一组参数列表,这组列表的参数将会一一传给测试方法。
清单 7. p-unit 参数化测试案例
上述代码的执行结果为:
清单 8. p-unit 参数化测试案例输出
从上述结果看出,每个方法被执行了 2 次,每次传入不同的参数。多线程运行参数化测试程序?相信读者已经明白怎么去实现了,只需将 PUnitSoloRunner 替换成 PUnitConcurrentRunner。
随着 Java 开源,出现了更多的 Java 运行环境,除了 SUN 的参考实现外,BEA、IBM 均有自己的 Java 运行环境,更有如 Apache Harmony 的开源运行环境(尽管现在 Apache Harmony 尚不能称为 Java 运行环境)。运行环境测试案例,为运行环境开发者以及选择运行环境,都能提供一定的帮助。比如说下面的例子就是测试 java.util.ArrayList 和 java.util.Vector 在两个不同运行环境的表现。测试案例写法和普通的测试案例完全一样,我们只需告诉 p-unit 不同的运行环境的 Java 路径以及正确的 classpath,然后调用 runVMs 函数即可:
清单 9. p-unit 运行环境测试案例
上述代码的运行结果如下:
图 1. 运行环境测试案例结果
从上图中可以很直观的看出,笔者使用的 HARMONY 版本在该测试案例中速度更快(左图),但内存消耗更多(右图)。下一节将讲述如何输出报表,但或许你已经注意到了,代码非常简单。
从上面的实例中我们已经看到 p-unit 的输出结果的两种形式,控制台和报表图片。默认情况下,p-unit 将输出到控制台。p-unit 采用事件机制,在运行器的每个节点都会提供通知事件。所有的输出都是通过注册事件响应器来实现的。这也表明了结果输出和运行器完全隔离,用户也可以定制自己的报表。p-unit 有 4 种内建输出,分别为控制台、文件、图片报表以及 PDF 报表。上一节的例子中我们已经看到图片报表,其代码为:
清单 10. 添加 p-unit 总体图片报表
p-unit 内建的报表有分三种不同的粒度:总体级别(OverviewReporter),TestSutie 级别(TestSuiteReporter),以及测试案例类级别(TestClassReporter)。这三种级别都可以输出图片格式或是 PDF 格式,因此,总共有六种类型的输出。上述的代码就是输出总体级别的图片。由于事件监听器是互相独立的,因此你可以既选择输出图片又选择输出 PDF 文件,只需再添加事件监听器即可:
清单 11. 添加多个 p-unit 事件监听器
总结
至此,你是否基本理解了 p-unit 的概念呢?简单,易用,关注多线程,关注性能,这就是 p-unit。此外 p-unit 还有很多很好的小特性,如 Alphabetical 接口来保证执行测试函数的先后顺序等。使用 p-unit,让你的代码更健壮!