Come aggiungere una copertura di test a un costruttore privato?

Questo è il codice:

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

Questo è il test:

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

Funziona bene, la classe è testata. Ma Cobertura dice che non c'è copertura del codice del costruttore privato della classe. Come possiamo aggiungere una copertura di test a un costruttore così privato?

Bene, ci sono modi in cui potresti potenzialmente usare la riflessione, ecc. - Ma ne vale davvero la pena? Questo è un costruttore che non dovrebbe mai essere chiamato , giusto?

Se c'è un'annotazione o qualcosa di simile che puoi aggiungere alla classe per far capire a Cobertura che non verrà chiamata, fallo: non penso che valga la pena fare i cerchi per aggiungere una copertura artificialmente.

EDIT: Se non c'è modo di farlo, vivi con una copertura leggermente ridotta. Ricorda che la copertura deve essere qualcosa di utile per te : dovresti essere responsabile dello strumento, non il contrario.

Non sono del tutto d'accordo con Jon Skeet. Penso che se puoi ottenere una vittoria facile per darti copertura ed eliminare il rumore nel tuo rapporto sulla copertura, allora dovresti farlo. Dì al tuo strumento di copertura di ignorare il costruttore, o metti da parte l'idealismo e scrivi il seguente test e finisci con esso:

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

Sebbene non sia necessariamente per la copertura, ho creato questo metodo per verificare che la classe di utilità sia ben definita e anche per fare un po 'di copertura.

/**
 * 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);
        }
    }
}

Ho inserito il codice completo e gli esempi in https://github.com/trajano/maven-jee6/tree/master/maven-jee6-test

Avevo reso privato il costruttore della mia classe di funzioni di utilità statiche, per soddisfare CheckStyle. Ma come il poster originale, avevo Cobertura che si lamentava del test. All'inizio ho provato questo approccio, ma ciò non influisce sul report di copertura perché il costruttore non viene mai effettivamente eseguito. Quindi, in realtà, tutto questo test è se il costruttore rimane privato - e questo è reso ridondante dal controllo dell'accessibilità nel test successivo.

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

Sono andato con il suggerimento di Javid Jamae e ho usato la riflessione, ma ho aggiunto affermazioni per catturare qualcuno che scherzava con la classe in fase di test (e ho chiamato il test per indicare 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());
}

Questo è così eccessivo, ma devo ammettere che mi piace la calda sensazione sfocata della copertura del metodo al 100%.

Con Java 8 è possibile trovare altre soluzioni.

Presumo che tu voglia semplicemente creare una classe di utilità con pochi metodi statici pubblici. Se puoi usare Java 8, puoi usare interfaceinvece.

package com.XXX;

public interface Foo {

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

Non c'è nessun costruttore e nessun reclamo da Cobertura. Ora devi testare solo le linee che ti interessano veramente.

Il ragionamento alla base del test del codice che non fa nulla è ottenere una copertura del codice del 100% e notare quando la copertura del codice diminuisce. Altrimenti si potrebbe sempre pensare, ehi, non ho più una copertura del codice al 100% ma è PROBABILMENTE a causa dei miei costruttori privati. Ciò semplifica l'individuazione di metodi non testati senza dover verificare che si tratti solo di un costruttore privato. Man mano che la base del codice cresce, sentirai davvero una bella sensazione di calore guardando il 100% invece del 99%.

IMO è meglio usare la riflessione qui poiché altrimenti dovresti ottenere uno strumento di copertura del codice migliore che ignori questi costruttori o in qualche modo dire allo strumento di copertura del codice di ignorare il metodo (forse un'annotazione o un file di configurazione) perché allora saresti bloccato con uno specifico strumento di copertura del codice.

In un mondo perfetto tutti gli strumenti di copertura del codice ignorerebbero i costruttori privati ​​che appartengono a una classe finale perché il costruttore è lì come misura di "sicurezza" nient'altro :)
Io userei questo codice:

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

Le versioni più recenti di Cobertura hanno il supporto integrato per ignorare banali getter / setter / costruttori:

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

Ignora banale

Ignora banale consente la possibilità di escludere costruttori / metodi che contengono una riga di codice. Alcuni esempi includono solo una chiamata a un supercostruttore, metodi getter / setter, ecc. Per includere l'argomento ignora banale aggiungere quanto segue:

<cobertura-instrument ignoreTrivial="true" />

o in una build Gradle:

cobertura {
    coverageIgnoreTrivial = true
}

Non farlo. Qual è il punto nel testare un costruttore vuoto? Poiché cobertura 2.0 esiste un'opzione per ignorare questi casi banali (insieme a setter / getter), puoi abilitarlo in maven aggiungendo la sezione di configurazione al plugin cobertura maven:

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

In alternativa è possibile utilizzare copertura Annotazioni : @CoverageIgnore.

Finalmente c'è la soluzione!

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

Non so Cobertura ma uso Clover e ha un mezzo per aggiungere esclusioni di corrispondenza dei modelli. Ad esempio, ho modelli che escludono le righe di registrazione di apache-commons in modo che non vengano conteggiati nella copertura.

Un'altra opzione è creare un inizializzatore statico simile al codice seguente

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

  // real ops
}

In questo modo il costruttore privato viene considerato testato e il sovraccarico di runtime non è fondamentalmente misurabile. Lo faccio per ottenere una copertura del 100% utilizzando EclEmma, ​​ma probabilmente funziona per ogni strumento di copertura. Lo svantaggio di questa soluzione, ovviamente, è che scrivi codice di produzione (l'inizializzatore statico) solo a scopo di test.

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

A volte Cobertura contrassegna il codice non destinato ad essere eseguito come "non coperto", non c'è niente di sbagliato in questo. Perché ti preoccupi di avere una 99%copertura invece di 100%?

Tecnicamente, però, puoi ancora invocare quel costruttore con la riflessione, ma mi suona molto sbagliato (in questo caso).

Se dovessi indovinare l'intento della tua domanda direi:

1. Desideri controlli ragionevoli per i costruttori privati ​​che svolgono un lavoro effettivo e
2. Vuoi che clover escluda i costruttori vuoti per le classi util.

Per 1, è ovvio che si desidera che tutta l'inizializzazione venga eseguita tramite metodi di fabbrica. In questi casi, i tuoi test dovrebbero essere in grado di testare gli effetti collaterali del costruttore. Questo dovrebbe rientrare nella categoria dei normali test con metodo privato. Rendi i metodi più piccoli in modo che eseguano solo un numero limitato di cose determinate (idealmente, solo una cosa e una cosa bene) e quindi testare i metodi che si basano su di essi.

Ad esempio, se il mio costruttore [privato] imposta i campi di istanza della mia classe asu 5. Quindi posso (o meglio devo) testarlo:

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

Per 2, puoi configurare clover per escludere i costruttori Util se hai un modello di denominazione impostato per le classi Util. Ad esempio, nel mio progetto uso qualcosa di simile (perché seguiamo la convenzione secondo la quale i nomi per tutte le classi Util dovrebbero terminare con Util):

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

Ho deliberatamente tralasciato un .*seguito )perché tali costruttori non hanno lo scopo di generare eccezioni (non hanno lo scopo di fare nulla).

Ovviamente può esserci un terzo caso in cui potresti voler avere un costruttore vuoto per una classe non di utilità. In questi casi, ti consiglio di inserire una methodContextcon la firma esatta del costruttore.

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

Se hai molte di queste classi eccezionali, puoi scegliere di modificare il costruttore privato generalizzato reg-ex che ho suggerito e rimuoverlo Util. In questo caso, dovrai assicurarti manualmente che gli effetti collaterali del tuo costruttore siano ancora testati e coperti da altri metodi nella tua classe / progetto.

<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 è il tuo file sorgente, che ha il tuo costruttore privato

Quanto segue ha funzionato per me su una classe creata con l'annotazione Lombok @UtilityClass, che aggiunge automaticamente un costruttore privato.

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

Sebbene constructor.setAccessible (true) dovrebbe funzionare quando il costruttore privato è stato scritto manualmente, con l'annotazione Lombok non funziona, poiché lo forza. Constructor.newInstance () verifica effettivamente che il costruttore sia invocato e questo completa la copertura del costruttore stesso. Con assertThrows eviti che il test fallisca e hai gestito l'eccezione poiché è esattamente l'errore che ti aspetti. Sebbene questa sia una soluzione alternativa e non apprezzo il concetto di "copertura di linea" rispetto a "copertura di funzionalità / comportamento", possiamo trovare un senso in questo test. Infatti sei sicuro che la Utility Class abbia effettivamente un Constructor privato che lancia correttamente un'eccezione quando invocato anche tramite reflaction. Spero che questo ti aiuti.

La mia opzione preferita nel 2019: usa lombok.

Nello specifico, l' @UtilityClassannotazione . (Purtroppo solo "sperimentale" al momento della scrittura, ma funziona perfettamente e ha una prospettiva positiva, quindi è probabile che presto verrà aggiornato a stabile.)

Questa annotazione aggiungerà il costruttore privato per impedire la creazione di istanze e renderà la classe finale. Se combinato con lombok.addLombokGeneratedAnnotation = truein lombok.config, praticamente tutti i framework di test ignoreranno il codice generato automaticamente durante il calcolo della copertura del test, consentendo di aggirare la copertura di quel codice generato automaticamente senza hack o riflessioni.

Non puoi.

Apparentemente stai creando il costruttore privato per impedire la creazione di istanze di una classe che dovrebbe contenere solo metodi statici. Piuttosto che cercare di ottenere la copertura di questo costruttore (il che richiederebbe l'istanza della classe), dovresti sbarazzartene e fidarti dei tuoi sviluppatori per non aggiungere metodi di istanza alla classe.