개인 생성자에 테스트 커버리지를 추가하는 방법은 무엇입니까?

다음은 코드입니다.

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

이것은 테스트입니다.

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
  }
}

잘 작동하고 클래스가 테스트됩니다. 그러나 Cobertura는 클래스의 개인 생성자에 대한 코드 커버리지가 없다고 말합니다. 이러한 개인 생성자에 테스트 커버리지를 어떻게 추가 할 수 있습니까?

글쎄, 당신이 잠재적으로 리플렉션 등을 사용할 수있는 방법이 있습니다-하지만 그만한 가치가 있습니까? 이것은 절대 호출 되어서는 안되는 생성자입니다 .

Cobertura가 호출되지 않는다는 것을 이해하도록 클래스에 추가 할 수있는 주석 또는 이와 유사한 것이있는 경우 그렇게하십시오. 인위적으로 커버리지를 추가하기 위해 후프를 거칠 가치가 없다고 생각합니다.

편집 : 그것을 할 방법이 없다면 약간 감소 된 범위로 생활하십시오. 커버리지는 당신에게 유용한 것임을 기억하세요. 당신은 도구를 담당해야합니다.

나는 Jon Skeet에 전적으로 동의하지 않습니다. 커버리지를 제공하고 커버리지 보고서의 소음을 제거 할 수있는 쉬운 승리를 얻을 수 있다면 그렇게해야한다고 생각합니다. 커버리지 도구에 생성자를 무시하도록 지시하거나 이상주의를 제쳐두고 다음 테스트를 작성하여 수행하십시오.

@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();
}

반드시 커버리지를위한 것은 아니지만 유틸리티 클래스가 잘 정의되어 있는지 확인하고 약간의 커버리지를 수행하기 위해이 메서드를 만들었습니다.

/**
 * 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을 만족시키기 위해 내 정적 유틸리티 함수 클래스의 생성자를 private으로 만들었습니다. 그러나 원래 포스터와 마찬가지로 Cobertura가 테스트에 대해 불평했습니다. 처음에는이 방법을 시도했지만 생성자가 실제로 실행되지 않기 때문에 커버리지 보고서에 영향을 미치지 않습니다. 따라서 실제로이 모든 테스트는 생성자가 비공개로 유지되는 경우입니다.이 테스트는 후속 테스트에서 접근성 검사에 의해 중복됩니다.

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

나는 Javid Jamae의 제안을 따르고 반성을 사용했지만 테스트중인 클래스를 망쳐 놓은 사람을 잡기 위해 단언을 추가했습니다 (그리고 테스트 이름은 High Levels Of Evil을 나타냄).

@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 % 메서드 커버리지의 따뜻한 퍼지 느낌이 좋아요.

Java 8을 사용하면 다른 솔루션을 찾을 수 있습니다.

공개 정적 메서드가 거의없는 유틸리티 클래스를 간단히 만들고 싶다고 가정합니다. Java 8을 사용할 수 있으면 interface대신 사용할 수 있습니다 .

package com.XXX;

public interface Foo {

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

Cobertura에서는 생성자도없고 불평도 없습니다. 이제 정말 관심있는 라인 만 테스트하면됩니다.

아무것도하지 않는 코드를 테스트하는 이유는 100 % 코드 커버리지를 달성하고 코드 커버리지가 떨어질 때를 알아 차리는 것입니다. 그렇지 않으면 항상 생각할 수 있습니다. 더 이상 100 % 코드 커버리지가 없지만 개인 생성자 때문에 가능성이 있습니다. 이렇게하면 개인 생성자인지 확인하지 않고도 테스트되지 않은 메서드를 쉽게 찾을 수 있습니다. 코드베이스가 커짐에 따라 실제로 99 %가 아닌 100 %를 보면 따뜻한 느낌이들 것입니다.

IMO에서는 리플렉션을 사용하는 것이 가장 좋습니다. 특정 코드 커버리지 도구로.

완벽한 세상에서 모든 코드 커버리지 도구는 최종 클래스에 속하는 개인 생성자를 무시할 것입니다. 생성자가 "보안"측정 값으로 다른 것은 없기 때문입니다.)
이 코드를 사용합니다.

    @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());
        }
    }

최신 버전의 Cobertura에는 사소한 게터 / 세터 / 생성자를 무시할 수있는 내장 지원 기능이 있습니다.

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

사소한 것 무시

Ignore trivial은 코드 한 줄을 포함하는 생성자 / 메소드를 제외하는 기능을 허용합니다. 몇 가지 예에는 super constrctor에 대한 호출, getter / setter 메소드 등이 포함됩니다. ignore 간단한 인수를 포함하려면 다음을 추가하십시오.

<cobertura-instrument ignoreTrivial="true" />

또는 Gradle 빌드에서 :

cobertura {
    coverageIgnoreTrivial = true
}

하지마. 빈 생성자를 테스트하는 이유는 무엇입니까? cobertura 2.0부터 이러한 사소한 경우를 무시할 수있는 옵션이 있습니다 (setter / getter와 함께), cobertura maven 플러그인에 구성 섹션을 추가하여 maven에서 활성화 할 수 있습니다.

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

또는 당신이 사용할 수있는 범위 주석 : @CoverageIgnore.

마지막으로 해결책이 있습니다!

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

Cobertura에 대해 잘 모르지만 Clover를 사용하며 패턴 일치 제외를 추가하는 수단이 있습니다. 예를 들어, apache-commons-logging 라인을 제외하는 패턴이 있으므로 적용 범위에 포함되지 않습니다.

또 다른 옵션은 다음 코드와 유사한 정적 이니셜 라이저를 만드는 것입니다.

class YourClass {
  private YourClass() {
  }
  static {
     new YourClass();
  }

  // real ops
}

이렇게하면 개인 생성자가 테스트 된 것으로 간주되고 런타임 오버 헤드는 기본적으로 측정 할 수 없습니다. EclEmma를 사용하여 100 % 커버리지를 얻기 위해이 작업을 수행하지만 모든 커버리지 도구에서 효과가있을 수 있습니다. 물론이 솔루션의 단점은 테스트 목적으로 만 프로덕션 코드 (정적 이니셜 라이저)를 작성한다는 것입니다.

ClassUnderTest testClass = Whitebox.invokeConstructor (ClassUnderTest.class);

때때로 Cobertura는 실행되도록 의도되지 않은 코드를 '덮어지지 않음'으로 표시합니다. 99%대신 보험 적용에 관심이있는 이유100% 입니까?

기술적으로는 여전히 리플렉션을 사용하여 해당 생성자를 호출 할 수 있지만이 경우에는 매우 잘못된 것 같습니다.

질문의 의도를 추측한다면 다음과 같이 말하고 싶습니다.

1. 실제 작업을 수행하는 개인 생성자에 대한 합리적인 검사를 원합니다.
2. clover가 util 클래스에 대해 빈 생성자를 제외하려고합니다.

1의 경우 모든 초기화가 공장 방법을 통해 수행되기를 원한다는 것이 분명합니다. 이러한 경우 테스트는 생성자의 부작용을 테스트 할 수 있어야합니다. 이것은 일반적인 비공개 메서드 테스트의 범주에 속해야합니다. 제한된 수의 결정적인 작업 만 수행하도록 메서드를 더 작게 만든 다음 (이상적으로는 한 가지, 한 가지만 잘 수행) 이에 의존하는 메서드를 테스트합니다.

예를 들어, 내 [private] 생성자가 내 클래스의 인스턴스 필드 a를 5. 그런 다음 테스트 할 수 있습니다 (또는 테스트해야합니다).

@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 클래스에 대해 설정된 이름 지정 패턴이있는 경우 Util 생성자를 제외하도록 clover를 구성 할 수 있습니다. 예를 들어, 내 프로젝트에서 다음과 같은 것을 사용합니다 (모든 Util 클래스의 이름이 Util로 끝나야한다는 규칙을 따르기 때문입니다).

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

일부러 .*다음 항목을 생략했습니다.)그러한 생성자는 예외를 던지는 것을 의미하지 않기 때문에 (아무것도 할 수 없습니다).

물론 비 유틸리티 클래스에 대해 빈 생성자를 원할 수있는 세 번째 경우가있을 수 있습니다. 이러한 경우 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>

이러한 예외적 인 클래스가 많은 경우 내가 제안한 일반화 된 개인 생성자 reg-ex를 수정하고 제거하도록 선택할 수 있습니다 Util. 이 경우 생성자의 부작용이 여전히 테스트되고 클래스 / 프로젝트의 다른 메서드에 의해 처리되는지 수동으로 확인해야합니다.

<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는 개인 생성자가있는 소스 파일입니다.

다음은 개인 생성자를 자동으로 추가하는 Lombok 주석 @UtilityClass로 만든 클래스에서 저에게 일했습니다.

@Test
public void testConstructorIsPrivate() throws IllegalAccessException, InvocationTargetException, InstantiationException, NoSuchMethodException {
    Constructor<YOUR_CLASS_NAME> constructor = YOUR_CLASS_NAME.class.getDeclaredConstructor();
    assertTrue(Modifier.isPrivate(constructor.getModifiers())); //this tests that the constructor is private
    constructor.setAccessible(true);
    assertThrows(InvocationTargetException.class, () -> {
        constructor.newInstance();
    }); //this add the full coverage on private constructor
}

constructor.setAccessible (true)는 개인 생성자가 수동으로 작성된 경우 작동해야하지만 Lombok 주석은 강제로 작동하지 않기 때문에 작동하지 않습니다. Constructor.newInstance ()는 실제로 생성자가 호출되었는지 테스트하고 이것은 costructor 자체의 범위를 완료합니다. assertThrows를 사용하면 테스트가 실패하는 것을 방지하고 예상 한 오류와 정확히 일치하므로 예외를 관리했습니다. 이것은 해결 방법이고 "라인 범위"대 "기능 / 행동 범위"의 개념을 이해하지 못하지만이 테스트에서 의미를 찾을 수 있습니다. 실제로 유틸리티 클래스에는 reflaction을 통해 호출 될 때 예외를 올바르게 throw하는 개인 생성자가 실제로 있다고 확신합니다. 도움이 되었기를 바랍니다.

2019 년에 제가 선호하는 옵션 : 롬복을 사용하세요.

특히 @UtilityClass주석 . (슬프게도 글을 쓰는 시점에는 "실험적"일 뿐이지 만 잘 작동하고 긍정적 인 전망을 가지고 있으므로 곧 안정으로 업그레이드 될 가능성이 높습니다.)

이 주석은 인스턴스화를 방지하기 위해 개인 생성자를 추가하고 클래스를 최종적으로 만듭니다. lombok.addLombokGeneratedAnnotation = truein 과 결합하면 lombok.config거의 모든 테스트 프레임 워크가 테스트 범위를 계산할 때 자동 생성 된 코드를 무시하므로 해킹이나 반사없이 자동 생성 된 코드의 적용 범위를 우회 할 수 있습니다.

당신은 할 수 없습니다.

정적 메서드 만 포함하도록 의도 된 클래스의 인스턴스화를 방지하기 위해 개인 생성자를 만드는 것 같습니다. 이 생성자 (클래스가 인스턴스화되어야 함)에 대한 커버리지를 얻으려고 시도하는 대신, 생성자를 제거하고 개발자가 클래스에 인스턴스 메서드를 추가하지 않도록 신뢰해야합니다.