¿Cómo agregar cobertura de prueba a un constructor privado?

Este es el código:

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

Esta es la prueba:

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

Funciona bien, la clase está probada. Pero Cobertura dice que no hay cobertura de código del constructor privado de la clase. ¿Cómo podemos agregar cobertura de prueba a un constructor tan privado?

Bueno, hay formas en las que podrías usar la reflexión, etc., pero ¿realmente vale la pena? Este es un constructor que nunca debería llamarse , ¿verdad?

Si hay una anotación o algo similar que pueda agregar a la clase para que Cobertura entienda que no se llamará, hágalo: no creo que valga la pena pasar por aros para agregar cobertura artificialmente.

EDITAR: Si no hay forma de hacerlo, simplemente viva con la cobertura ligeramente reducida. Recuerde que la cobertura está destinado a ser algo que es útil para usted - usted debe estar a cargo de la herramienta, y no al revés.

No estoy del todo de acuerdo con Jon Skeet. Creo que si puede obtener una ganancia fácil para brindarle cobertura y eliminar el ruido en su informe de cobertura, entonces debería hacerlo. Dile a tu herramienta de cobertura que ignore al constructor, o deja a un lado el idealismo y escribe la siguiente prueba y termina con ella:

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

Aunque no es necesariamente para cobertura, creé este método para verificar que la clase de utilidad esté bien definida y que también tenga un poco de cobertura.

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

He colocado el código completo y los ejemplos en https://github.com/trajano/maven-jee6/tree/master/maven-jee6-test

Hice privado el constructor de mi clase de funciones de utilidad estática, para satisfacer CheckStyle. Pero al igual que el póster original, Cobertura se quejó de la prueba. Al principio probé este enfoque, pero esto no afecta el informe de cobertura porque el constructor nunca se ejecuta realmente. Entonces, realmente todas estas pruebas son si el constructor permanece privado, y esto se vuelve redundante por la verificación de accesibilidad en la prueba posterior.

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

Seguí la sugerencia de Javid Jamae y usé la reflexión, pero agregué afirmaciones para atrapar a cualquiera que se metiera con la clase que se estaba probando (y nombré la prueba para indicar 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());
}

Esto es tan exagerado, pero debo admitir que me gusta la sensación cálida y difusa de la cobertura del método al 100%.

Con Java 8 , es posible encontrar otra solución.

Supongo que simplemente desea crear una clase de utilidad con pocos métodos estáticos públicos. Si puede usar Java 8, puede usarlo interfaceen su lugar.

package com.XXX;

public interface Foo {

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

No hay constructor y no se quejan de Cobertura. Ahora necesita probar solo las líneas que realmente le interesan.

El razonamiento detrás de probar el código que no hace nada es lograr una cobertura del código del 100% y darse cuenta de cuándo cae la cobertura del código. De lo contrario, uno siempre podría pensar, oye, ya no tengo una cobertura de código del 100%, pero PROBABLEMENTE se debe a mis constructores privados. Esto facilita la detección de métodos no probados sin tener que verificar que solo sea un constructor privado. A medida que su código base crece, realmente sentirá una agradable sensación de calor al mirar al 100% en lugar del 99%.

En mi opinión, es mejor usar la reflexión aquí, ya que de lo contrario tendría que obtener una mejor herramienta de cobertura de código que ignore estos constructores o de alguna manera decirle a la herramienta de cobertura de código que ignore el método (tal vez una anotación o un archivo de configuración) porque entonces estaría atascado con una herramienta de cobertura de código específica.

En un mundo perfecto, todas las herramientas de cobertura de código ignorarían los constructores privados que pertenecen a una clase final porque el constructor está allí como una medida de "seguridad", nada más :)
Yo usaría este código:

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

Las versiones más nuevas de Cobertura tienen soporte incorporado para ignorar captadores / definidores / constructores triviales:

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

Ignorar trivial

Ignorar trivial permite la posibilidad de excluir constructores / métodos que contienen una línea de código. Algunos ejemplos incluyen una llamada a un superconstrctor solamente, métodos getter / setter, etc. Para incluir el argumento trivial ignorar agregue lo siguiente:

<cobertura-instrument ignoreTrivial="true" />

o en una compilación de Gradle:

cobertura {
    coverageIgnoreTrivial = true
}

No lo hagas. ¿Qué sentido tiene probar un constructor vacío? Dado que cobertura 2.0 hay una opción para ignorar estos casos triviales (junto con setters / getters), puede habilitarlo en maven agregando la sección de configuración al complemento cobertura maven:

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

Alternativamente, puede utilizar las anotaciones de cobertura : @CoverageIgnore.

¡Finalmente, hay una solución!

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

No sé sobre Cobertura, pero uso Clover y tiene un medio para agregar exclusiones de coincidencia de patrones. Por ejemplo, tengo patrones que excluyen líneas apache-commons-logging para que no se cuenten en la cobertura.

Otra opción es crear un inicializador estático similar al siguiente código

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

  // real ops
}

De esta manera, el constructor privado se considera probado y la sobrecarga del tiempo de ejecución básicamente no es medible. Hago esto para obtener una cobertura del 100% con EclEmma, ​​pero es probable que funcione para todas las herramientas de cobertura. El inconveniente de esta solución, por supuesto, es que escribe el código de producción (el inicializador estático) solo con fines de prueba.

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

A veces, Cobertura marca el código que no está destinado a ejecutarse como 'no cubierto', no hay nada de malo en eso. ¿Por qué le preocupa tener 99%cobertura en lugar de 100%?

Técnicamente, sin embargo, todavía puedes invocar ese constructor con reflexión, pero me suena muy mal (en este caso).

Si tuviera que adivinar la intención de su pregunta, diría:

1. Quiere verificaciones razonables para constructores privados que realicen un trabajo real, y
2. Desea que clover excluya los constructores vacíos para las clases de servicios.

Para 1, es obvio que desea que toda la inicialización se realice a través de métodos de fábrica. En tales casos, sus pruebas deberían poder probar los efectos secundarios del constructor. Esto debería caer en la categoría de prueba de método privado normal. Haga los métodos más pequeños para que solo hagan un número limitado de cosas determinadas (idealmente, solo una cosa y una cosa bien) y luego pruebe los métodos que se basan en ellos.

Por ejemplo, si mi constructor [privado] configura los campos de instancia de mi clase aen 5. Entonces puedo (o más bien debo) probarlo:

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

Para 2, puede configurar clover para excluir los constructores Util si tiene un patrón de nomenclatura establecido para las clases Util. Por ejemplo, en mi propio proyecto utilizo algo como esto (porque seguimos la convención de que los nombres de todas las clases de Util deben terminar con Util):

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

Deliberadamente he omitido un .*siguiente) porque tales constructores no están destinados a lanzar excepciones (no están destinados a hacer nada).

Por supuesto, puede haber un tercer caso en el que desee tener un constructor vacío para una clase que no sea de utilidad. En tales casos, le recomendaría que coloque un methodContextcon la firma exacta del constructor.

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

Si tiene muchas de estas clases excepcionales, puede elegir modificar el constructor privado generalizado reg-ex que sugerí y eliminarlo Util. En este caso, deberá asegurarse manualmente de que los efectos secundarios de su constructor aún se prueben y cubran con otros métodos en su clase / proyecto.

<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 es su archivo fuente, que tiene su constructor privado

Lo siguiente me funcionó en una clase creada con la anotación de Lombok @UtilityClass, que agrega automáticamente un constructor privado.

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

Aunque constructor.setAccessible (true) debería funcionar cuando el constructor privado se ha escrito manualmente, con la anotación de Lombok no funciona, ya que la fuerza. Constructor.newInstance () en realidad prueba que se invoca al constructor y esto completa la cobertura del propio constructor. Con assertThrows evitas que la prueba falle y manejaste la excepción ya que es exactamente el error que esperas. Aunque esta es una solución alternativa y no aprecio el concepto de "cobertura de línea" frente a "cobertura de funcionalidad / comportamiento", podemos encontrar un sentido en esta prueba. De hecho, está seguro de que la clase de utilidad tiene en realidad un constructor privado que arroja correctamente una excepción cuando se invoca también mediante reflacción. Espero que esto ayude.

Mi opción preferida en 2019: usar lombok.

Específicamente, la @UtilityClassanotación . (Lamentablemente, solo es "experimental" en el momento de escribir este artículo, pero funciona bien y tiene una perspectiva positiva, por lo que es probable que pronto se actualice a estable).

Esta anotación agregará el constructor privado para evitar la creación de instancias y hará que la clase sea final. Cuando se combinan con lombok.addLombokGeneratedAnnotation = truein lombok.config, casi todos los marcos de prueba ignorarán el código generado automáticamente al calcular la cobertura de la prueba, lo que le permitirá omitir la cobertura de ese código generado automáticamente sin hacks ni reflejos.

No puedes.

Aparentemente, está creando el constructor privado para evitar la creación de instancias de una clase que está destinada a contener solo métodos estáticos. En lugar de intentar obtener cobertura de este constructor (lo que requeriría que la clase sea instanciada), debe deshacerse de él y confiar en que sus desarrolladores no agregarán métodos de instancia a la clase.