Il metodo Asserting sul tearDown (@After) è sbagliato?

Question

Ho anche più casi di test e se la logica è diversa, l'output deve essere uguale su tutti. Quindi stavo pensando a come generalizzarli e inserire il metodo Assert solo una volta.

Esiste un modo migliore per farlo che questo:

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() { 
    } 
} 

metodo di lavoro:

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

Answer 1

Sì, affermare nel metodo tearDown è una cattiva idea. Questo metodo esiste, secondo la documentazione di JUnit, a

Strappa l'apparecchio, ad esempio, chiude una connessione di rete. Questo metodo viene chiamato dopo l'esecuzione di un test.

Penso che memorizzare i valori previsti e quelli effettivi nella classe di test sia una cattiva idea in generale. Queste variabili dipendono dal test, quindi memorizzale all'interno del tuo test case e fai la tua affermazione nel caso di test. Ad esempio:

public class FooTest { 

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

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

} 

Inoltre, nel vostro codice vedo che tutti i test hanno lo stesso valore previsto. Potrebbe essere una buona idea variare i test in modo che i valori restituiti siano sempre diversi. Testando solo un valore previsto per tutto il tempo, assicurati che il codice funzioni per questo risultato previsto. Prova con un po 'di più, possibilmente molto diverso, e prova a provare alcuni casi d'angolo.

Answer 2

Se si deve generalizzare allora si potrebbe creare un metodo come

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

e chiamalo da tutti i tuoi metodi di prova.

Se e quando un test fallisce sarà più ovvio quale test non è riuscito.