转自:http://www.uml.org.cn/test/201211214.asp
背景介绍
最近参与了一个新产品的研发工作。新产品是采用模块式开发方式,拥有众多的功能模块,每一个模块是一个独立的 Java 工程。在产品中,为了保证各个模块的功能,目前其都有相应的 JUnit 测试程序。随着产品功能的逐渐完善,我们发现,程序中光是 JUnit Test 测试文件,全部加起来已经有几百个。由于这些文件分布在几十个不同的工程不同的子目录结构中,目前并没有很好的工具可以将所有的单元测试一次运行。而手工的运行这些单元测试是非常繁琐的,对程序员来说是浪费时间的;又或者可以用脚本完成运行所有测试文件的目的,但是由于我们采取的是敏捷开发的模式,JUnit Test 测试集合会不断的持续增长,每增加一个 JUnit Test 文件,就需要立即修改脚本;一旦忘记修改,这个新加的测试文件可能就无法被执行可见,用脚本来执行测试文件也并不是很好的手段,依然给我们的开发带来额外工作。这里我们有了一个想法,做一个全局的单元测试程序,去自动的检索工程集中所有的 JUnit Test 测试程序。这个全局单元测试程序将基于 JUnit4 去运行。
核心机制:JUnit4 支持一次运行多个测试程序
首先我们要了解 JUnit4 支持多个 Class 集合作为输入,并且调用 org.junit.runner.Runner.run() 方法运行输入的测试类集合。JUnit4 中已经定义了一些默认的 Runner,可以分别处理不同的输入类集合:比如 BlockJUnit4ClassRunner,就是默认处理带有 @Test 的 JUnit4 测试类的运行器;Suite,可以处理兼容 JUnit3 的测试类的运行器,等等。
我们可以来看下面的 Runner 结构图:
图 1. JUnit Runner 结构图
Runner 类定义了运行测试用例的接口,Suite 类继承自 Runner 类,Suite 类支持 JUnit3 风格的测试类,可以用来执行多个测试用例。因此我们的想法是,自定义一个继承自 Suite 类的 Runner,就是上图中得 AllClassRunner 类。这个 Runner 的输入将是工程集中所有找到的 JUnit Test Class 集合,这样就可以一次运行工程中不同工程不同目录下的所有 JUnit Test 文件了。下面是我们的 AllClassRunner 类的代码:
清单 1. AllClassRunner 类的代码
public class AllJunitTestRunner extends Suite { public AllJunitTestRunner(Class<?> clazz, RunnerBuilder builder) throws InitializationError { // 调用父类 Suite 方法直接运行所有符合要求的 JUnit Test 对象 super(builder, clazz, loadAllTestClass(filterClassNameList (clazz, loadAllClassesName(clazz)))); } } |
loadAllClassesName 方法将会找到工程集中所有的 Class 文件名的集合,filterClassNameList 将会对找到的 Class 文件集合进行过滤,过滤条件是针对文件名称。loadAllTestClass 则会找到所有符合条件的 JUnitTest Class 集合。
如何找到所有的需要的 JUnit Test 测试类集合
我们来看下面的流程图:
图 2. 找到需要的 JUnit Test Class 对象集合的流程图
流程图要素介绍:
- 找到工程集内所有的 .class 文件名
- 对找到的文件名集合根据过滤条件进行初步过滤
- 根据 .class 文件名转换到相应的 Class 对象
- 判断是否属于 Abstract 类,如果不是的话,继续判断
- 判断是否属于 Inner 类,如果不是的话,继续判断
- 判断是否属于 JUnit3 或者 JUnit4 风格的类,如果是的话,加入结果集
- 经过上述步骤,将找到所有需要的 JUnit Test class 集合。将找到的 Class 集合放入到自定义 Runner 中,可以达到一次运行工程集内所有测试程序的目的。
如何找出所有的 Class 文件名集合
首先根据默认的 Java classpath 属性,找到当前运行的 JUnit Test 文件所在工程集中所有的文件及文件夹:
清单 2. 找到工程集中所有 Jar 及 .Class 所在目录集合
public static String getClasspath() { return System.getProperty(CONSTANT.DEFAULT_CLASSPATH_PROPERTY); } |
这里得到的将是一个路径集合的 String 对象,包括文件目录及 .jar 文件(jar 文件内也包含 Class 文件名)。我们需要做的,是找到文件目录下的 Class 文件,因此通过 split 这个路径集合,剔除里面的 .jar 文件,我们将得到一个包含工程集中所有 Class 文件的目录集合。
因为 Class 文件可能会嵌套的包含在我们找到的目录集合中,所以我们需要递归的去找到所有的 Class 文件,并将 Class 文件的 Class 名放到一个集合中,示例代码如下:
清单 3. 递归找到工程集中所有的 Class 对象集合
for (String path : Util.splitClassPath(Util.getClasspath())) { // 此处不处理 Jar 包文件,感兴趣的读者可以考虑自己添加对 Jar 包中 JUnit Test 文件的处理 if (!(path.toLowerCase().endsWith(CONSTANT.JAR_SUFFIX))) { Util.loadAllClassNames(path, path, classesFileNameList); } } public static void loadAllClassNames(String rootPath, String currentPath, List<String> classNameList) { File currentFile = new File(currentPath); if (currentFile.isFile()) { // 如果是文件的话,直接将路径名转换为文件名,并加入结果集 if (Util.isClassFile(currentFile.getName())) { classNameList.add( Util.replaceFileSeparator( Util.removeClassSuffix( // 只获取文件的名字,并将路径中的反斜杠”/”转换为文件名中的”.” // 比如获取文件名为”com.aa.bb.cc” Util.getFileNameWithoutRootPath(currentFile, rootPath)))); } } else { // 如果是文件夹的话,则取所有的子文件,递归处理所有取到的子文件 for (File file : currentFile.listFiles()) { if (file.isFile()) { if (Util.isClassFile(file.getName())) { classNameList.add(Util.replaceFileSeparator(Util.removeClassSuffix (Util.getFileNameWithoutRootPath(file, rootPath)))); } } else { loadAllClassNames(rootPath, file.getAbsolutePath(), classNameList); } } } } |
上面我们得到的将是所有一个 List<String> 对象,包含所有的 .class 文件。
如何过滤 Class 文件名
可以自定义一系列的过滤条件,比如对于 package “com.aa.bb.cc”下的所有 JUnit Test 文件都不测试,那么可以写如下的 filter:
清单 4. 对 Class 名字使用过滤条件的示例代码
public static boolean classNameIsInArray(String className) { String filters = "com.aa.bb.cc1.*;com.aa.bb.cc2.*"; String[] filterList = filters.split(";"); if (filters == null || filterList.length < 1) { return false; } for (String pattern : filterList) { if (className.matches(pattern)) { return true; } } return false; } |
如何过滤 Abstract 类
我们知道一个 JUnit Test 文件绝对不可能是 Abstract 类,因此可以把 Abstract 类从 Class 集合中首先过滤掉。示例代码如下:
清单 5. 过滤 Abstract 类的示例代码
public static boolean isAbstractClass(Class<?> clazz) { return (clazz.getModifiers()&Modifier.ABSTRACT) != 0; } |
如何过滤 Inner 类
JUnit Test 类中一般来说不允许再定义一个子类,因此对于 Inner class 来说,也是我们的剔除对象。示例代码展示如何找到 Inner 类。
清单 6. 过滤 Inner 类的示例代码
public static final String INNER_CLASS_CHAR = "$"; public static boolean isInnerClass(String className) { return className.contains(INNER_CLASS_CHAR); } |
如何找到 JUnit3 文件
首先我们来看一个典型的基于 JUnit3 的单元测试程序:
清单 7. 典型 JUnit3 风格的测试代码
import junit.framework.TestCase; import static org.junit.Assert.*; public class AddOperationTest extends TestCase{ public void setUp() throws Exception { } public void tearDown() throws Exception { } // 测试方法必须以 test 开头 public void testAdd() { int x = 0; int y = 0; AddOperation instance = new AddOperation(); int expResult = 0; int result = instance.add(x, y); assertEquals(expResult, result); } } |
我们可以看到上面的单元测试拥有如下特征:
1.继承自 junit.framework.TestCase 类;
2.要测试的方法以 test 开头。
在这里我们只需要知道一个 .class 文件是否是 JUnit3 的测试程序,因此第二条特征暂时用不上,我们用是否继承自 TestCase 类来作为判断标准,代码如下:
清单 8. 找出 JUnit3 风格的 JUnit Test 测试文件的示例代码
public static boolean isJUnit3TestClass(Class<?> clazz) { // class.isAssignableFrom() 方法可以找到即使是父类的父类的继承关系 // 因此认为如果输入的子类继承自 JUnit Test3.8 的 TestCase 类,则认为是 JUnit3 风格的 JUnit Test 类对象 return TestCase.class.isAssignableFrom(clazz); } |
如果是继承自 TestCase 这个类,则返回 true,代表是 JUnit3 的单元测试; 否则返回 false;.
如何找到 JUnit4 文件
对于 JUnit4,我们知道它最大的特征是引入了 Annotation 机制,简化了原来的单元测试的用法。我们可以来看下面的例子:
清单 9. 典型 JUnit4 风格的测试代码
import junit.framework.TestCase; import org.junit.After; import org.junit.Before; import org.junit.Test; import static org.junit.Assert.*; public class AddOperationTest extends TestCase{ @Before public void setUp() throws Exception { } @After public void tearDown() throws Exception { } @Test public void add() { int x = 0; int y = 0; AddOperation instance = new AddOperation(); int expResult = 0; int result = instance.add(x, y); assertEquals(expResult, result); } } |
我们可以看到上面的 JUnit4 测试程序拥有如下特征:
1.继承自 junit.framework.TestCase 类;
2.拥有至少一个有 @Test 的注释的测试方法,且方法名称任意
因此对于 JUnit4 的 Class 文件来说,我们需要判断的是它的方法内是否有 @Test Annotation,如果没有的话,就不是一个有效的 JUnit4 测试文件。示例代码如下:
清单 10. 找出 JUnit4 风格的 JUnit Test 测试文件的示例代码
public static boolean isJUnit4TestClass(Class<?> clazz) { try { for (Method method : clazz.getMethods()) { // 如果在 class 对象所有的方法中发现 @Test 注释,则认为是 JUnit4 风格的 JUnit Test 对象 if (method.getAnnotation(Test.class) != null) { return true; } } } catch (NoClassDefFoundError ignore) { return false; } return false; } |
使用各种过滤条件
前面我们已经得到了一个在本工程集内的所有 Class 文件的集合,现在我们可以使用各种过滤条件对集合进行过滤,示例代码如下:
清单 11. 联合使用各种过滤条件找出需要的 JUnit Test 的示例代码
for (String className : classesFileNameList) { Class<?> classFromName = null; try { // 从 class 名字转换为 class 对象 classFromName = Class.forName(className); } catch (ClassNotFoundException e) { // 如果转换失败,则跳过 continue; } // JUnit Test class 对象不可能是内部 class,所以跳过检测所有的内部 class if (!Util.isInnerClass(className)) { Class<?> classFromName = Class.forName(className); if (classFromName.isLocalClass()|| classFromName.isAnonymousClass()) { // JUnit Test class 对象也不可能是 local 或者 Anonymous 对象,跳过 continue; } if (!Util.isAbstractClass(classFromName) && (Util.isJUnit4TestClass(classFromName)|| Util.isJUnit38TestClass(classFromName))) { toBeRanTestClassList.add(classFromName); } } } |
这里我们找到的 toBeRanTestClassList 集合就是我们期望测试的 JUnit Test Class 对象集合。
JUnit 自动执行所有测试
现在我们已经有了自己的 AllJUnitTestRunner,也找到了工程集内所有的 JUnit Test Class 集合。下面要做的就是如何运行找到的 Class 集合。具体代码如下:
清单 12. 我们的期望值 - 最终的 JUnit Test 示例代码
import org.junit.runner.RunWith; import junit.AllJunitTestRunner; @RunWith(AllJunitTestRunner.class) public class AllJunitTest { } |
只需要一个空的 JUnitTest 测试文件,并将 AllJUnitTestRunner 作为这个测试文件的 Runner。那么在运行这个测试程序时,它将调用我们定义的 Runner 去自动运行所有我们期望的 JUnit Test 测试程序。是不是很方便呢?可以说基本达到了我们预期的目的。
改进点
我们知道在 JUnit4 中支持自定义的 Annotation,因此对于我们的各种过滤项,应该可以通过定义新的 Annotation 方式从而在最终的 JUnit Test 程序中任意定义,这样比硬编码在全局单元测试程序模块内更加方便使用。
递归查找整个工程集内所有的 class 文件名会对查找速度产生影响。本人觉得在递归的同时应该可以再次对路径名等进行过滤,避免在不必要的目录内不停的查找,以提高性能。
以上是本人目前想到的 2 个改进点,希望大家踊跃讨论,提高程序的性能及易用性。
总结
本文主要利用了 Class 文件的各种特征及 JUnit3、JUnit4 的特征,及 JUnit4 中可以一次执行多个 JUnit Test 文件的特性,达到一次执行全部工程集内的所有测试文件的目的。目前,在实际项目执行中起到了非常大的作用。对于所有新增的功能点,新增的测试文件,在正式上传到服务器之前都只需要执行一个 JUnit Test 文件,就可以发现是否影响原有功能,增加了程序开发过程的自动性,节约了大量程序开发纠错的时间,提高了产品的质量。