Wie kann der Quellcode von der Coverage-Messung in IntelliJ IDEA ausgeschlossen werden?

Question

In einem Projekt, ich habe eine Utility-Klasse, die wie folgt aussieht:

public final class Util { 
    private Util() {} 
    public static String method1(InputStream in) {...} 
    public static String method2(BufferedReader in) {...} 
    public static String method3(File file) {...} 
} 

Die Klasse ist eine Utility-Klasse in dem Sinne, dass es nur static Methoden enthält. Daher wird es final erklärt und sein Konstruktor ist private. Das Erstellen von Instanzen oder das Ableiten von Unterklassen würde einfach keinen Sinn ergeben.

Ich habe eine Reihe von Komponententests, die das Projekt testet. Ich verwende IntelliJ IDEA, um die Tests auszuführen, messen und visualisieren die Code-Abdeckung. Der Konstruktor des Dienstprogramms class Util reduziert jetzt die Abdeckung. Ich möchte eine 100% auf 100% logische Abdeckung sehen. Code wie der private Konstruktor der Utility-Klasse reduziert die Abdeckung.

Gibt es eine Möglichkeit, vorzugsweise durch eine Annotation, eine Methode oder einen Konstruktor als nicht relevant für die Codeabdeckung zu markieren, um diesen Code aus den Coverage Reports auszuschließen und damit eine 100% ige Abdeckung anzuzeigen?

Ich weiß, dass im Allgemeinen verstecken Code aus dem Coverage-Bericht zu Ihrem eigenen Nachteil liegt. Es würde mir nichts ausmachen, wenn der Bericht eine Liste von "ignorierten Items" hätte - eigentlich wäre das gut, um zu überprüfen, ob jemand Dinge ignoriert, die nicht ignoriert werden sollten. Der Punkt ist wirklich über Code, für den Abdeckung keinen Sinn macht, wie der private Konstruktor einer Utility-Klasse.

Ich habe versucht zu finden, ob annotations.jar einen Kandidaten enthält. Die einzige Anmerkung, die sogar entfernt aussah, als ob sie es könnte, war TestOnly, aber sie erfüllt diesen Zweck nicht. Ich guckte auch in plugins/coverage/lib/*.jar und konnte keinen Kandidaten finden, aber vielleicht habe ich es gerade verpasst?

Answer 1

Ich benutze enum für Dienstprogramm Klassen und die meisten Coverage-Tools wissen, es zu ignorieren Methoden.

public enum Util { ; 

enum sind final mit private Konstrukteuren standardmäßig.

Answer 2

Diese Frage ist derzeit über ein Jahr alt; Ich dachte jedoch, ich könnte eine Alternative bieten, private Konstrukteure in Komponententests zu ignorieren. Obwohl es ziemlich unwahrscheinlich ist, ist es möglich, einen privaten Konstruktor in Java zu umgehen. Außerdem könnte die Klasse in der Zukunft geändert werden, jemand könnte einen Konstruktor hinzufügen usw. Wenn ein Komponententest dies überprüft, kann dies redundant wirken, aber es fügt eine weitere Klarheitsebene hinzu. Ein fehlgeschlagener Komponententest würde mir sicherlich auffallen. "Ich habe einen Komponententest zum Scheitern gebracht. Bin ich sicher, dass ich weiß, was ich hier ändere?"

Ohne weiteres hier ein paar Beispielcode.

Hier haben wir eine Klasse mit einem privaten Konstruktor.

public final class ClassWithPrivateCtor 
{ 
    private ClassWithPrivateCtor() 
    { 
    throw new AssertionError(String.format(
     "Illegal instantiation of class: %s.", 
     this.getClass().getName())); 
    } 
} 

Dies ist eine Möglichkeit, einen privaten Konstruktor in Java aufzurufen.

private static <T> void invokePrivateConstructor(final Class<T> type) 
    throws Throwable 
{ 
    final Constructor<T> constructor = type.getDeclaredConstructor(); 

    constructor.setAccessible(true); 

    try 
    { 
    constructor.newInstance(); 
    } 
    catch (InvocationTargetException ex) 
    { 
    throw ex.getTargetException(); 
    } 
} 

Und das ist, wie ich es in meinen Komponententests verwende.

@Test(
    description = "Verify ClassWithPrivateCtor private constructor fails.", 
    expectedExceptions = AssertionError.class) 
public void classWithPrivateCtorTest() 
    throws Throwable 
{ 
    invokePrivateConstructor(ClassWithPrivateCtor.class); 
} 

Ich habe es sich zur Gewohnheit gemacht auf diese Weise private Konstruktoren nur um zu überprüfen, über die ursprüngliche Absicht der Klasse klar zu sein, ob es ein Utility-Klasse oder eine Klasse mit Konstanten etc ...