Divisione di un test a una serie di test più piccoli

Question

Voglio dividere un test di grandi dimensioni in test più piccoli in modo che quando superano i test più piccoli implicano anche il superamento del test di grandi dimensioni (quindi non c'è motivo di eseguire il test prova originale grande). Voglio farlo perché i test più piccoli di solito richiedono meno tempo, meno sforzo e sono meno fragili. Vorrei sapere se ci sono schemi di progettazione di test o strumenti di verifica che possono aiutarmi a ottenere questo risultato in modo robusto.

Temo che la connessione tra i test più piccoli e il test originale venga persa quando qualcuno cambia qualcosa nel set di test più piccoli. Un altro timore è che il set di test più piccoli non copre realmente il big test.

Un esempio di quello che sto puntando a:

//Class under test 
class A { 

    public void setB(B b){ this.b = b; } 

    public Output process(Input i){ 
    return b.process(doMyProcessing(i)); 
    } 

    private InputFromA doMyProcessing(Input i){ .. } 

    .. 

} 

//Another class under test 
class B { 

    public Output process(InputFromA i){ .. } 

    .. 

} 

//The Big Test 
@Test 
public void theBigTest(){ 
A systemUnderTest = createSystemUnderTest(); // <-- expect that this is expensive 

Input i = createInput(); 

Output o = systemUnderTest.process(i); // <-- .. or expect that this is expensive 

assertEquals(o, expectedOutput()); 
} 

//The splitted tests 

@PartlyDefines("theBigTest") // <-- so something like this should come from the tool.. 
@Test 
public void smallerTest1(){ 
    // this method is a bit too long but its just an example.. 
    Input i = createInput(); 
    InputFromA x = expectedInputFromA(); // this should be the same in both tests and it should be ensured somehow 
    Output expected = expectedOutput(); // this should be the same in both tests and it should be ensured somehow 

    B b = mock(B.class); 
    when(b.process(x)).thenReturn(expected); 

    A classUnderTest = createInstanceOfClassA(); 
    classUnderTest.setB(b); 

    Output o = classUnderTest.process(i); 

    assertEquals(o, expected); 
    verify(b).process(x); 
    verifyNoMoreInteractions(b); 
} 

@PartlyDefines("theBigTest") // <-- so something like this should come from the tool.. 
@Test 
public void smallerTest2(){ 
    InputFromA x = expectedInputFromA(); // this should be the same in both tests and it should be ensured somehow 
    Output expected = expectedOutput(); // this should be the same in both tests and it should be ensured somehow 

    B classUnderTest = createInstanceOfClassB(); 

    Output o = classUnderTest.process(x); 

    assertEquals(o, expected); 
} 

Answer 1

Il primo suggerimento che farò è di ridimensionare i test su rosso (in mancanza). Per fare ciò, dovrai interrompere temporaneamente il tuo codice di produzione. In questo modo, sai che i test sono ancora validi.

Un modello comune consiste nell'utilizzare un dispositivo di prova separato per raccolta di test "grandi". Non è necessario attenersi al modello "tutti i test per una classe in una classe di test". Se una serie di test sono correlati tra loro, ma non sono correlati ad un altro insieme di test, quindi inserirli nella loro classe.

Il più grande vantaggio nell'usare una classe separata per contenere i singoli test piccoli per il test di grandi dimensioni è che è possibile sfruttare i metodi di installazione e di rimozione. Nel tuo caso, vorrei spostare le linee che hanno commentato con:

// this should be the same in both tests and it should be ensured somehow

al metodo di installazione (in JUnit, un metodo annotato con @Before). Se è necessario eseguire alcune impostazioni insolitamente costose, la maggior parte dei framework di testing xUnit ha un modo per definire un metodo di installazione che viene eseguito una volta prima di tutti i test. In JUnit, questo è un metodo public static void con l'annotazione @BeforeClass.

Se i dati di test sono immutabili, tendo a definire le variabili come costanti.

Mettendo insieme tutto questo, si potrebbe avere qualcosa di simile:

public class TheBigTest { 

    // If InputFromA is immutable, it could be declared as a constant 
    private InputFromA x; 
    // If Output is immutable, it could be declared as a constant 
    private Output expected; 

    // You could use 
    // @BeforeClass public static void setupExpectations() 
    // instead if it is very expensive to setup the data 
    @Before 
    public void setUpExpectations() throws Exception { 
     x = expectedInputFromA(); 
     expected = expectedOutput(); 
    } 

    @Test 
    public void smallerTest1(){ 
     // this method is a bit too long but its just an example.. 
     Input i = createInput(); 

     B b = mock(B.class); 
     when(b.process(x)).thenReturn(expected); 

     A classUnderTest = createInstanceOfClassA(); 
     classUnderTest.setB(b); 

     Output o = classUnderTest.process(i); 

     assertEquals(o, expected); 
     verify(b).process(x); 
     verifyNoMoreInteractions(b); 
    } 

    @Test 
    public void smallerTest2(){ 
     B classUnderTest = createInstanceOfClassB(); 

     Output o = classUnderTest.process(x); 

     assertEquals(o, expected); 
    } 

} 

Answer 2

Tutto quello che posso suggerire è il libro xUnit Test Patterns. Se c'è una soluzione dovrebbe essere lì.

Answer 3

theBigTest manca la dipendenza B. Anche la dipendenza smallerTest1 gestisce la dipendenza da B. In smallerTest2 dovresti prendere in giro InputFromA.

Perché hai creato un grafico delle dipendenze come hai fatto?

A prende un B poi quando A::processInput, poi post-elaborazione InputFromA in B.

Conservare il test e il refactor grande A e B per modificare il mapping delle dipendenze.

[EDIT] in risposta alle osservazioni.

@mkorpela, il mio punto è che, guardando il codice e le loro dipendenze è come si inizia ad avere un'idea di come creare test più piccoli. A ha una dipendenza su B. In modo che esso per completare il suo process() si deve usare B s' process(). Per questo motivo, B ha una dipendenza su A.