¿Debo dividir los métodos para su reutilización en JUnit?

Question

Tengo la siguiente prueba JUnit. El método que estoy probando es bastante simple, simplemente recibe un número y devuelve una lista con sus divisores. No quiero repetir el código de prueba muchas veces, así que he creado un método auxiliar, testDivisorsAux:

@Test 
public final void testDivisors() { 
    testDivisorsAux(1, new int[] { 1 }); 
    testDivisorsAux(6, new int[] { 1, 2, 3, 6 }); 
    testDivisorsAux(0, new int[] { }); 
    ... 
} 

private final void testDivisorsAux(final int number, final int[] expected) { 
    List<Integer> divisors = Util.divisors(number); 
    assertSame(divisors.size(), expected.length); 
    for (int i : expected) { 
     assertTrue(divisors.contains(i)); 
    } 
} 

Todo funciona bien, me pregunto ... es esta una mala práctica? ¿Debo escribir la prueba de otra manera? Tal vez mantener todo el código dentro del "método @Test"?

PMD me está diciendo que las pruebas JUnit deben incluir assert() o no() (para el primer método), y JUnit 4 pruebas que se ejecutan las pruebas deben utilizar la anotación @test (para el segundo) . Sé que PMD está usando solo una expresión regular (bueno, en realidad es XPath) para determinar qué reglas estoy rompiendo ... así que me inclino a pensar que es simplemente una advertencia de "falso positivo". Pero de todos modos, me gustaría saber si estoy haciendo algo mal. (Aparte de escribir pruebas 4 veces más que el método está probado :)

Mientras yo estaba buscando preguntas similares a éste, he encontrado algo que se llama pruebas parametrizados ... pero parece que es algo orientado a escenarios mucho más grandes, ¿no?

Answer 1

Personalmente creo que es buena práctica para hacer esto. Existe un pequeño peligro de ir demasiado lejos y generar grandes cantidades de código para hacer su prueba, en cuyo caso debe reconsiderar el diseño de las cosas que está probando. Realmente no quiere tener que escribir pruebas para evaluar sus pruebas, pero el ejemplo que da parece estar bien y significa que sus casos de prueba son mucho más simples.

No he usado PMD y personalmente intentaría configurarlo para utilizar estas advertencias. Si te preocupan, es posible que puedas cambiar tu código para deshacerte de ellos. Supongo que la segunda advertencia fue porque tu método de ayuda comienza con la palabra prueba. En junit3 todos los métodos que comienzan con la prueba son pruebas. ¿Por qué no renombrar el método testDivisorsAux para ser assertDivisors? Tal vez tener un método que comience con assert ayude también con la primera advertencia.

Answer 2

Como sugirió Adam Butler, tener un método que comience con assert resolverá esta advertencia.

En su caso, renombre testDivisorsAux para assertDivisorsAux lo arreglará.

Consulte también http://pmd.sourceforge.net/pmd-4.3.0/xref/net/sourceforge/pmd/rules/junit/JUnitTestsShouldContainAsserts.html para ver el código que verifica la regla.