如何将testing覆盖率添加到私有构造函数?

这是代码:

package com.XXX; public final class Foo { private Foo() { // intentionally empty } public static int bar() { return 1; } } 

这是testing:

 package com.XXX; public FooTest { @Test void testValidatesThatBarWorks() { int result = Foo.bar(); assertEquals(1, result); } @Test(expected = java.lang.IllegalAccessException.class) void testValidatesThatClassFooIsNotInstantiable() { Class cls = Class.forName("com.XXX.Foo"); cls.newInstance(); // exception here } } 

工作正常,class级进行testing。 但是Cobertura说这个类的私有构造函数的代码覆盖率是零。 我们如何将testing覆盖率添加到这样的私人构造函数?

那么,有很多方法可以使用reflection等 – 但它真的值得吗? 这是一个不应该被调用的构造函数,对吧?

如果有一个注释或类似的东西,你可以添加到课堂上让Cobertura明白它不会被调用,那么这样做:我不认为值得通过人为增加覆盖率。

编辑:如果没有办法做到这一点,只是略有减less的覆盖面。 请记住,覆盖范围是对有用的东西 – 你应该负责工具,而不是相反。

我不完全赞同Jon Skeet。 我认为,如果您可以轻松取胜,为您提供报道并消除报道报道中的噪音,那么您应该这样做。 要么告诉你的覆盖工具忽略构造函数,要么把理想主义放在一边,写下面的testing,并用它来完成:

 @Test public void testConstructorIsPrivate() throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException { Constructor<Foo> constructor = Foo.class.getDeclaredConstructor(); assertTrue(Modifier.isPrivate(constructor.getModifiers())); constructor.setAccessible(true); constructor.newInstance(); } 

虽然这不一定是覆盖范围,但是我创build了这个方法来validation实用程序类是否定义良好,并进行一些覆盖。

 /** * Verifies that a utility class is well defined. * * @param clazz * utility class to verify. */ public static void assertUtilityClassWellDefined(final Class<?> clazz) throws NoSuchMethodException, InvocationTargetException, InstantiationException, IllegalAccessException { Assert.assertTrue("class must be final", Modifier.isFinal(clazz.getModifiers())); Assert.assertEquals("There must be only one constructor", 1, clazz.getDeclaredConstructors().length); final Constructor<?> constructor = clazz.getDeclaredConstructor(); if (constructor.isAccessible() || !Modifier.isPrivate(constructor.getModifiers())) { Assert.fail("constructor is not private"); } constructor.setAccessible(true); constructor.newInstance(); constructor.setAccessible(false); for (final Method method : clazz.getMethods()) { if (!Modifier.isStatic(method.getModifiers()) && method.getDeclaringClass().equals(clazz)) { Assert.fail("there exists a non-static method:" + method); } } } 

我已经把完整的代码和例子放在https://github.com/trajano/maven-jee6/tree/master/maven-jee6-test

我已经使我的类静态实用函数的构造函数,以满足CheckStyle。 但是就像原来的海报一样,我让Cobertura抱怨这个testing。 起初,我尝试了这种方法,但是这不会影响覆盖率报告,因为构造函数从未被实际执行过。 所以所有这些testing都是在构造函数保持私有的情况下进行的 – 在随后的testing中,通过可访问性检查,这会变得冗余。

 @Test(expected=IllegalAccessException.class) public void testConstructorPrivate() throws Exception { MyUtilityClass.class.newInstance(); fail("Utility class constructor should be private"); } 

我和Javid Jamae的build议一起使用,并使用了反思,但是join了一些断言,让任何人搞乱了正在testing的类(并且把这个testing命名为“高级恶魔”)。

 @Test public void evilConstructorInaccessibilityTest() throws Exception { Constructor[] ctors = MyUtilityClass.class.getDeclaredConstructors(); assertEquals("Utility class should only have one constructor", 1, ctors.length); Constructor ctor = ctors[0]; assertFalse("Utility class constructor should be inaccessible", ctor.isAccessible()); ctor.setAccessible(true); // obviously we'd never do this in production assertEquals("You'd expect the construct to return the expected type", MyUtilityClass.class, ctor.newInstance().getClass()); } 

这太过分了,但我得承认我喜欢100%方法覆盖的温暖的模糊感觉。

testing代码背后的原因是要达到100%的代码覆盖率,并注意代码覆盖率何时下降。 否则,人们总是会想,嘿,我没有100%的代码覆盖率,但可能是因为我的私人构造函数。 这使得很容易发现未经testing的方法,而不必检查它是否是一个私有的构造函数。 随着你的代码库的增长,你会觉得100%而不是99%的温暖感。

海事组织最好在这里使用reflection,否则你将不得不得到一个更好的代码覆盖工具,忽略这些构造函数或以某种方式告诉代码覆盖工具忽略该方法(可能是一个注释或configuration文件),因为那样你会卡住使用特定的代码覆盖工具。

在完美的世界中,所有代码覆盖工具都会忽略属于最终类的私有构造函数,因为构造函数在那里是作为“安全”度量的,没有别的东西:)
我会用这个代码:

  @Test public void callPrivateConstructorsForCodeCoverage() throws SecurityException, NoSuchMethodException, IllegalArgumentException, InstantiationException, IllegalAccessException, InvocationTargetException { Class<?>[] classesToConstruct = {Foo.class}; for(Class<?> clazz : classesToConstruct) { Constructor<?> constructor = clazz.getDeclaredConstructor(); constructor.setAccessible(true); assertNotNull(constructor.newInstance()); } } 

然后,只要将数组添加到数组中即可。

使用Java 8 ,可以find其他解决scheme。

我假设你只是想用less数的公共静态方法创build工具类。 如果你可以使用Java 8,那么你可以使用interface

 package com.XXX; public interface Foo { public static int bar() { return 1; } } 

没有build设者,也没有来自Cobertura的抱怨。 现在你只需要testing你真正关心的行。

较新版本的Cobertura内置了对忽略getter / setter / constructor的简单支持:

https://github.com/cobertura/cobertura/wiki/Ant-Task-Reference#ignore-trivial

忽略微不足道

忽略微不足道允许排除包含一行代码的构造函数/方法的能力。 一些例子只包括对super constrctor的调用,getter / setter方法等。要包含ignore trivial参数,请添加以下内容:

 <cobertura-instrument ignoreTrivial="true" /> 

或者在Gradle构build中:

 cobertura { coverageIgnoreTrivial = true } 

最后,有解决scheme!

 public enum Foo {; public static int bar() { return 1; } } 

别。 testing一个空的构造函数有什么意义? 由于cobertura 2.0有一个选项可以忽略这些微不足道的情况(与setter / getters一起),你可以在maven中通过向cobertura maven插件添加configuration部分来启用它:

 <configuration> <instrumentation> <ignoreTrivial>true</ignoreTrivial> </instrumentation> </configuration> 

或者,您可以使用Coverage Annotations : @CoverageIgnore

我不知道Cobertura,但我使用Clover,它有添加模式匹配排除的手段。 例如,我有排除apache-commons-logging行的模式,所以它们不计入覆盖范围。

另一个选项是创build一个类似于以下代码的静态初始化程序

 class YourClass { private YourClass() { } static { new YourClass(); } // real ops } 

这样私人的构造函数被认为是testing,运行时开销基本上是不可测量的。 我这样做是为了使用EclEmma来获得100%的覆盖率,但是对于每个覆盖率工具来说可能都是可行的。 当然,这个解决scheme的缺点是你只是为了testing目的而编写产品代码(静态初始化器)。

有时候,Cobertura标记的代码并不打算作为“未被覆盖”执行,这没有什么错。 你为什么要关心99%覆盖而不是100%

不过从技术上讲,你仍然可以用reflection来调用构造函数,但是这对我来说听起来是非常错误的(在这种情况下)。

如果我猜测你的问题的意图,我会说:

  1. 你需要合理的检查做实际工作的私人构造函数
  2. 您希望三叶草排除util类的空构造函数。

对于1来说,显然你想通过工厂方法来完成所有的初始化。 在这种情况下,你的testing应该能够testing构造函数的副作用。 这应该属于正常的私人方法testing的范畴。 使这些方法变得更小,以便只做有限数量的确定性事物(理想情况下只是一件事,一件事),然后testing依赖它们的方法。

例如,如果我的[私人]构造函数设置我的类的实例字段a5 。 那么我可以(或者更确切地说)testing它:

 @Test public void testInit() { MyClass myObj = MyClass.newInstance(); //Or whatever factory method you put Assert.assertEquals(5, myObj.getA()); //Or if getA() is private then test some other property/method that relies on a being 5 } 

对于2,如果您为Util类设置了命名模式,则可以将三叶草configuration为排除Util构造函数。 例如,在我自己的项目中,我使用类似这样的东西(因为我们遵循惯例,所有Util类的名称都应该以Util结尾):

 <clover-setup initString="${build.dir}/clovercoverage.db" enabled="${with.clover}"> <methodContext name="prvtCtor" regexp="^private *[a-zA-Z0-9_$]+Util *( *) *"/> </clover-setup> 

我故意留下一个.*后面的)因为这样的构造函数并不是要抛出exception(它们并不意味着什么)。

当然可以有第三种情况,你可能想要一个非实用类的空构造函数。 在这种情况下,我会build议你把一个methodContext与构造函数的确切签名。

 <clover-setup initString="${build.dir}/clovercoverage.db" enabled="${with.clover}"> <methodContext name="prvtCtor" regexp="^private *[a-zA-Z0-9_$]+Util *( *) *"/> <methodContext name="myExceptionalClassCtor" regexp="^private MyExceptionalClass()$"/> </clover-setup> 

如果你有很多这样的特殊类,那么你可以select修改我build议的通用私有构造函数reg-ex,并从中删除Util 。 在这种情况下,您将不得不手动确保您的构造函数的副作用仍然在您的类/项目中被其他方法testing和覆盖。

 <clover-setup initString="${build.dir}/clovercoverage.db" enabled="${with.clover}"> <methodContext name="prvtCtor" regexp="^private *[a-zA-Z0-9_$]+ *( *) .*"/> </clover-setup> 
 @Test public void testTestPrivateConstructor() { Constructor<Test> cnt; try { cnt = Test.class.getDeclaredConstructor(); cnt.setAccessible(true); cnt.newInstance(); } catch (Exception e) { e.getMessage(); } } 

Test.java是你的源文件,它有你的私有构造函数

你不能。

你显然创build了私有构造函数,以防止只包含静态方法的类的实例化。 而不是试图得到这个构造函数的覆盖(这将需要类实例化),你应该摆脱它,并相信你的开发人员不要向类中添加实例方法。