¿Es incorrecto afirmarse en el método tearDown (@After)?

Question

Tengo múltiples casos de prueba incluso y si la lógica es diferente, la salida debe ser igual en todos ellos. Así que estaba pensando en cómo generalizarlos y colocar el método Assert una sola vez.

¿Hay alguna forma mejor de hacerlo que éste:

static public class Tests() { 

    private static String expected = null; 
    private String actual = null; 

    @BeforeClass 
    public static void setUpBeforeClass() throws Exception { 
     expected = new String("My Desired Output"); 
    } 

    @Before 
    public void setUp() { 
     actual = new String(); 
    } 

    @Test 
    public void test1() throws Exception { 
     actual = ... 
    } 

    @Test 
    public void test2() throws Exception { 
     actual = ... 
    } 

    @After 
    public void tearDown() throws Exception { 
     assertThat(actual, is(equalTo(expected))); 
    } 

    @AfterClass 
    public static void tearDownAfterClass() { 
    } 
} 

método Duración:

@Test 
public void runTests() { 
    Result result = JUnitCore.runClasses(Tests.class); 
    assertThat(result.getRunCount(), is(2)); 
    assertThat(result.getFailureCount(), is(0)); 
} 

Answer 1

Sí, afirmar en el método tearDown es una mala idea. Este método existe, de acuerdo con la documentación de JUnit, en

Desgarra el dispositivo, por ejemplo, cierra una conexión de red. Este método se invoca después de que se ejecuta una prueba.

Creo que almacenar sus valores esperados y reales en la clase de prueba es una mala idea en general. Estas variables dependen de la prueba, así que guárdalas dentro de tu caso de prueba y haz tu afirmación en el caso de prueba. Por ejemplo:

public class FooTest { 

    @Test 
    public void testFoo() { 
     Object expected = // ... 
     Object actual = // ... 

     assertThat(actual, is(equalsTo(expected))); 
    } 

} 

Además, veo en su código que todas las pruebas tienen el mismo valor esperado. Puede ser una buena idea variar sus pruebas para que los valores devueltos sean siempre diferentes. Al probar solo un valor esperado todo el tiempo, se asegura de que el código funcione para este resultado esperado. Pruebe con algo más, posiblemente muy diferente, y trate de probar algunos casos de esquina.

Answer 2

Si debe generalizar a continuación, se puede crear un método como

private void testIt (String actual) { 
    assertThat(actual, is(equalTo(expected))); 
} 

y llámalo desde todos tus métodos de prueba.

Si y cuando falla una prueba, será más obvio qué prueba falló.