Perché Mockito salta l'inizializzazione della variabile membro della mia classe astratta

Question

Sto provando a testare una classe astratta e Mockito non inizializza le mie variabili membro. Ecco un semplice esempio per mostrarti il ​​mio problema.

Questa è una classe astratta che inizializza il proprio 'campo' membro:

import java.util.ArrayList; 
import java.util.Collection; 

public abstract class Foo { 
    private final Collection field = new ArrayList(); 

    protected Foo() { 
     System.out.println("In constructor"); 
    } 

    public boolean isNull(Object o) { 
     field.add(o); 

     return o == null; 
    } 

    abstract void someAbstractMethod(); 
} 

Qui la classe di test:

import org.junit.Assert; 
import org.junit.Test; 
import org.mockito.Mockito; 

public class FooTest { 
    @Test 
    public void testSomething() { 
     final Foo foo = Mockito.mock(Foo.class); 

     Mockito.when(foo.isNull(Mockito.anyObject())).thenCallRealMethod(); 

     Assert.assertFalse(foo.isNull("baaba")); 
    } 
} 

Quando il test viene eseguito getta un NPE perché il campo variabile' 'non è inizializzato!

Cosa sto sbagliando?

Answer 1

Questo è il comportamento previsto, quando si prende in giro qualcosa l'istanza creata è una simulazione completa, quindi non ha senso inizializzare i campi poiché il comportamento è predefinito.

A parte ciò, i campi possono essere inizializzati da un costruttore in classi concrete o astratte, poiché l'istanziazione dei mock bypassa il costruttore semplicemente perché è una simulazione, è ancora più irrazionale inizializzarli.

Cercare di chiamare il metodo reale di solito è sbagliato quando si usano i mock. Invece si dovrebbe bloccare il comportamento della simulazione.

Mockito.when(foo.isNull(Mockito.anyObject())).thenReturn(false); 
Assert.assertFalse(foo.isNull("baaba")); // assertion always passing 

io non conosco il tuo caso d'uso effettivo, ma forse si vuole un mock parziali, con un spy. Anche se questo è ancora considerato una cattiva pratica in quanto di solito significa che è necessario rifattorizzare il codice per utilizzare la composizione.

Answer 2

Sembra che tu stia prendendo in giro la classe che stai effettivamente cercando di testare. Non è proprio l'idea di prendere in giro. Ti prendi in giro le classi che non rientrano nell'ambito del test e lasci che la cosa che stai testando non sia bloccata.

In questo caso, dovresti probabilmente creare un Foo, con un'implementazione fittizia di someAbstractMethod e testarlo direttamente. Non c'è bisogno di deriderlo, per quanto posso vedere.