Deridere le variabili membro di una classe usando Mockito

Sono un novizio dello sviluppo e in particolare dei test unitari. Immagino che il mio requisito sia piuttosto semplice, ma sono curioso di conoscere i pensieri degli altri su questo.

Supponiamo che io abbia due classi così:

public class First {

    Second second ;

    public First(){
        second = new Second();
    }

    public String doSecond(){
        return second.doSecond();
    }
}

class Second {

    public String doSecond(){
        return "Do Something";
    }
}

Diciamo che sto scrivendo unit test per testare il First.doSecond()metodo. Tuttavia, supponiamo, voglio deridere la Second.doSecond()classe in questo modo. Sto usando Mockito per fare questo.

public void testFirst(){
    Second sec = mock(Second.class);
    when(sec.doSecond()).thenReturn("Stubbed Second");

    First first = new First();
    assertEquals("Stubbed Second", first.doSecond());
}

Vedo che la derisione non ha effetto e l'asserzione fallisce. Non c'è modo di deridere le variabili membro di una classe che voglio testare. ?

È necessario fornire un modo per accedere alle variabili membro in modo da poter passare in modo fittizio (i modi più comuni sarebbero un metodo setter o un costruttore che accetta un parametro).

Se il codice non fornisce un modo per farlo, viene considerato in modo errato per TDD (Test Driven Development).

Ciò non è possibile se non è possibile modificare il codice. Ma mi piace l'iniezione di dipendenza e Mockito la supporta:

public class First {    
    @Resource
    Second second;

    public First() {
        second = new Second();
    }

    public String doSecond() {
        return second.doSecond();
    }
}

Il tuo test:

@RunWith(MockitoJUnitRunner.class)
public class YourTest {
   @Mock
   Second second;

   @InjectMocks
   First first = new First();

   public void testFirst(){
      when(second.doSecond()).thenReturn("Stubbed Second");
      assertEquals("Stubbed Second", first.doSecond());
   }
}

Questo è molto carino e facile.

Se osservi attentamente il tuo codice, vedrai che la secondproprietà nel tuo test è ancora un'istanza Second, non una simulazione (non passi la derisione firstnel tuo codice).

Il modo più semplice sarebbe quello di creare un setter per secondin Firstclasse e passarlo in modo esplicito.

Come questo:

public class First {

Second second ;

public First(){
    second = new Second();
}

public String doSecond(){
    return second.doSecond();
}

    public void setSecond(Second second) {
    this.second = second;
    }


}

class Second {

public String doSecond(){
    return "Do Something";
}
}

....

public void testFirst(){
Second sec = mock(Second.class);
when(sec.doSecond()).thenReturn("Stubbed Second");


First first = new First();
first.setSecond(sec)
assertEquals("Stubbed Second", first.doSecond());
}

Un altro sarebbe passare Secondun'istanza come Firstparametro del costruttore.

Se non riesci a modificare il codice, penso che l'unica opzione sarebbe quella di usare reflection:

public void testFirst(){
    Second sec = mock(Second.class);
    when(sec.doSecond()).thenReturn("Stubbed Second");


    First first = new First();
    Field privateField = PrivateObject.class.
        getDeclaredField("second");

    privateField.setAccessible(true);

    privateField.set(first, sec);

    assertEquals("Stubbed Second", first.doSecond());
}

Ma probabilmente puoi, dato che è raro fare test su codice che non controlli (anche se uno può immaginare uno scenario in cui devi testare una libreria esterna perché l'autore non l'ha fatto :))

Se non riesci a modificare la variabile membro, viceversa è utilizzare PowerMockit e chiamare

Second second = mock(Second.class)
when(second.doSecond()).thenReturn("Stubbed Second");
whenNew(Second.class).withAnyArguments.thenReturn(second);

Ora il problema è che QUALSIASI chiamata al nuovo Second restituirà la stessa istanza derisa. Ma nel tuo caso semplice funzionerà.

Ho avuto lo stesso problema in cui non è stato impostato un valore privato perché Mockito non chiama i super costruttori. Ecco come aumento beffardo con la riflessione.

Innanzitutto, ho creato una classe TestUtils che contiene molti utili programmi di utilità inclusi questi metodi di riflessione. L'accesso alla riflessione è un po 'complicato da implementare ogni volta. Ho creato questi metodi per testare il codice su progetti che, per un motivo o per l'altro, non avevano un pacchetto di simulazione e non sono stato invitato a includerlo.

public class TestUtils {
    // get a static class value
    public static Object reflectValue(Class<?> classToReflect, String fieldNameValueToFetch) {
        try {
            Field reflectField  = reflectField(classToReflect, fieldNameValueToFetch);
            reflectField.setAccessible(true);
            Object reflectValue = reflectField.get(classToReflect);
            return reflectValue;
        } catch (Exception e) {
            fail("Failed to reflect "+fieldNameValueToFetch);
        }
        return null;
    }
    // get an instance value
    public static Object reflectValue(Object objToReflect, String fieldNameValueToFetch) {
        try {
            Field reflectField  = reflectField(objToReflect.getClass(), fieldNameValueToFetch);
            Object reflectValue = reflectField.get(objToReflect);
            return reflectValue;
        } catch (Exception e) {
            fail("Failed to reflect "+fieldNameValueToFetch);
        }
        return null;
    }
    // find a field in the class tree
    public static Field reflectField(Class<?> classToReflect, String fieldNameValueToFetch) {
        try {
            Field reflectField = null;
            Class<?> classForReflect = classToReflect;
            do {
                try {
                    reflectField = classForReflect.getDeclaredField(fieldNameValueToFetch);
                } catch (NoSuchFieldException e) {
                    classForReflect = classForReflect.getSuperclass();
                }
            } while (reflectField==null || classForReflect==null);
            reflectField.setAccessible(true);
            return reflectField;
        } catch (Exception e) {
            fail("Failed to reflect "+fieldNameValueToFetch +" from "+ classToReflect);
        }
        return null;
    }
    // set a value with no setter
    public static void refectSetValue(Object objToReflect, String fieldNameToSet, Object valueToSet) {
        try {
            Field reflectField  = reflectField(objToReflect.getClass(), fieldNameToSet);
            reflectField.set(objToReflect, valueToSet);
        } catch (Exception e) {
            fail("Failed to reflectively set "+ fieldNameToSet +"="+ valueToSet);
        }
    }

}

Quindi posso testare la classe con una variabile privata come questa. Ciò è utile per deridere alberi profondi che non hai alcun controllo.

@Test
public void testWithRectiveMock() throws Exception {
    // mock the base class using Mockito
    ClassToMock mock = Mockito.mock(ClassToMock.class);
    TestUtils.refectSetValue(mock, "privateVariable", "newValue");
    // and this does not prevent normal mocking
    Mockito.when(mock.somthingElse()).thenReturn("anotherThing");
    // ... then do your asserts
}

Ho modificato il mio codice dal mio progetto attuale qui, nella pagina. Potrebbe esserci un problema di compilazione o due. Penso che tu abbia l'idea generale. Sentiti libero di prendere il codice e usarlo se lo trovi utile.

Molti altri ti hanno già consigliato di ripensare il tuo codice per renderlo più testabile: un buon consiglio e di solito più semplice di quello che sto per suggerire.

Se non riesci a modificare il codice per renderlo più testabile, PowerMock: https://code.google.com/p/powermock/

PowerMock estende Mockito (quindi non devi imparare un nuovo framework simulato), fornendo funzionalità aggiuntive. Ciò include la possibilità che un costruttore abbia restituito una simulazione. Potente, ma un po 'complicato, quindi usalo con giudizio.

Si utilizza un corridore Mock diverso. E devi preparare la classe che invocherà il costruttore. (Nota che questo è un gotcha comune: prepara la classe che chiama il costruttore, non la classe costruita)

@RunWith(PowerMockRunner.class)
@PrepareForTest({First.class})

Quindi, nella configurazione del test, è possibile utilizzare il metodo whenNew per fare in modo che il costruttore restituisca una simulazione

whenNew(Second.class).withAnyArguments().thenReturn(mock(Second.class));

Sì, questo può essere fatto, come mostra il seguente test (scritto con l'API di derisione JMockit, che sviluppo):

@Test
public void testFirst(@Mocked final Second sec) {
    new NonStrictExpectations() {{ sec.doSecond(); result = "Stubbed Second"; }};

    First first = new First();
    assertEquals("Stubbed Second", first.doSecond());
}

Con Mockito, tuttavia, tale test non può essere scritto. Ciò è dovuto al modo in cui il mocking viene implementato in Mockito, dove viene creata una sottoclasse della classe da deridere; solo le istanze di questa sottoclasse "finta" possono avere comportamenti derisi, quindi è necessario che il codice testato le usi invece di qualsiasi altra istanza.

Se vuoi un'alternativa a ReflectionTestUtils di Spring in mockito, usa

Whitebox.setInternalState(first, "second", sec);