プライベートコンストラクターにテストカバレッジを追加する方法

これはコードです：

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が呼び出されないことを理解するためにクラスに追加できる注釈または類似のものがある場合は、それを行います。人為的にカバレッジを追加するためにフープを通過する価値はないと思います。

編集：それを行う方法がない場合は、わずかにカバレッジを減らして生活してください。カバレッジはあなたにとって役立つものであることを忘れないでください -あなたはツールを担当するべきであり、逆ではありません。

私はジョン・スキートに完全に同意しません。カバレッジを提供し、カバレッジレポートのノイズを排除するための簡単な勝利を手に入れることができるなら、そうすべきだと思います。コンストラクターを無視するようにカバレッジツールに指示するか、理想主義を脇に置いて次のテストを記述し、それで完了します。

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

私はハビッドジャマエの提案に沿ってリフレクションを使用しましたが、テストされているクラスをいじる人をキャッチするアサーションを追加しました（そしてテストに悪の高レベルを示す名前を付けました）。

@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

些細なことを無視する

些細なことを無視すると、1行のコードを含むコンストラクタ/メソッドを除外できます。いくつかの例には、スーパーコンストラクターのみの呼び出し、getter / setterメソッドなどが含まれます。ignoretrivial引数を含めるには、以下を追加します。

<cobertura-instrument ignoreTrivial="true" />

またはGradleビルドで：

cobertura {
    coverageIgnoreTrivial = true
}

しないでください。空のコンストラクターをテストする意味は何ですか？cobertura 2.0にはこのような些細なケースを（セッター/ゲッターと共に）無視するオプションがあるため、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. クローバーにutilクラスの空のコンストラクターを除外させたいとします。

1の場合、すべての初期化をファクトリーメソッドを介して実行したいことは明らかです。そのような場合、テストはコンストラクターの副作用をテストできるはずです。これは、通常のプライベートメソッドテストのカテゴリに分類されます。メソッドを小さくして、限られた数の決定的なこと（理想的には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コンストラクターを除外するようにクローバーを構成できます。たとえば、私は自分のプロジェクトで次のようなものを使用しています（すべてのUtilクラスの名前はUtilで終わるという規則に従っているため）。

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

このようなコンストラクターは例外をスローすることを意図していないため、故意に.*以下)を省略しました（何も実行することを意図していません）。

もちろん、非ユーティリティクラスの空のコンストラクタが必要になる3番目のケースもあります。そのような場合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（）は実際にコンストラクターが呼び出されたことをテストし、これによりココンストラクター自体のカバレッジが完了します。assertThrowsを使用することで、テストが失敗することを防ぎ、例外を管理できます。これは、まさに予想されるエラーだからです。これは回避策であり、「ラインカバレッジ」対「機能性/動作カバレッジ」の概念を理解していませんが、このテストで感覚を見つけることができます。実際、ユーティリティクラスには、reflactionを介して呼び出された場合に例外を正しくスローするプライベートコンストラクターが実際にあることが確実です。お役に立てれば。

2019年の私の推奨オプション：ロンボクを使用します。

具体的には、@UtilityClassアノテーション。（残念ながら、執筆時点では「実験的」にすぎませんが、問題なく機能し、前向きな見通しを持っているため、間もなく安定版にアップグレードされます。）

このアノテーションは、インスタンス化を防ぐためにプライベートコンストラクターを追加し、クラスをfinalにします。lombok.addLombokGeneratedAnnotation = truein と組み合わせると、lombok.configほとんどすべてのテストフレームワークがテストカバレッジを計算するときに自動生成コードを無視するため、ハッキングやリフレクションなしで自動生成コードのカバレッジをバイパスできます。

できません。

静的メソッドのみを含むことを目的としたクラスのインスタンス化を防ぐために、プライベートコンストラクターを作成しているようです。このコンストラクタのカバレッジを取得しようとするのではなく（クラスをインスタンス化する必要があります）、それを取り除き、開発者がクラスにインスタンスメソッドを追加しないように信頼する必要があります。