Mockito - differenza tra doReturn () e when ()

Attualmente sto usando Mockito per deridere i miei oggetti del livello di servizio in un'applicazione Spring MVC in cui voglio testare i miei metodi Controller. Tuttavia, mentre leggevo i dettagli di Mockito, ho scoperto che i metodi doReturn(...).when(...)sono equivalenti when(...).thenReturn(...). Quindi, la mia domanda è: qual è il punto di avere due metodi che fanno la stessa cosa o qual è la sottile differenza tra doReturn(...).when(...)e when(...).thenReturn(...)?

Qualsiasi aiuto sarebbe apprezzato.

Le due sintassi per lo stub sono approssimativamente equivalenti. Tuttavia, puoi sempre usare doReturn/whenper il mozzicone; ma ci sono casi in cui non puoi usare when/thenReturn. Stubbing metodi vuoti è uno di questi. Altri includono l'uso con spie Mockito e lo stub dello stesso metodo più di una volta.

Una cosa che when/thenReturnti dà, doReturn/whenno, è la verifica del tipo del valore che stai restituendo, al momento della compilazione. Tuttavia, credo che questo non abbia quasi alcun valore: se hai sbagliato il tipo, lo scoprirai non appena eseguirai il test.

Consiglio vivamente di utilizzare solo doReturn/when. Non ha senso apprendere due sintassi quando si farà.

Potresti fare riferimento alla mia risposta in Formare "grammatiche" di Mockito , una risposta più dettagliata a una domanda strettamente correlata.

Entrambi gli approcci si comportano in modo diverso se si utilizza un oggetto spiato (annotato con @Spy) anziché un mock (annotato con @Mock):

• when(...) thenReturn(...) effettua una chiamata reale al metodo prima che venga restituito il valore specificato. Quindi, se il metodo chiamato genera un'eccezione, devi affrontarla / deriderla ecc. Naturalmente ottieni ancora il tuo risultato (quello che definisci in thenReturn(...))

• doReturn(...) when(...) non chiama affatto il metodo .

Esempio:

public class MyClass {
     protected String methodToBeTested() {
           return anotherMethodInClass();
     }

     protected String anotherMethodInClass() {
          throw new NullPointerException();
     }
}

Test:

@Spy
private MyClass myClass;

// ...

// would work fine
doReturn("test").when(myClass).anotherMethodInClass();

// would throw a NullPointerException
when(myClass.anotherMethodInClass()).thenReturn("test");

Il javadoc di Mockito sembra dire perché usare doReturn()invece di when() Usa doReturn () in quelle rare occasioni in cui non puoi usare Mockito.when (Object).

Attenzione che Mockito.when (Object) è sempre consigliato per lo stub perché è un argomento sicuro e più leggibile (specialmente quando si stubba chiamate consecutive).

Ecco quelle rare occasioni in cui doReturn () è utile:

1. Quando spiare oggetti reali e chiamare metodi reali su una spia porta effetti collaterali

List list = new LinkedList(); List spy = spy(list);

// Impossibile: il metodo reale è chiamato così spy.get (0) genera IndexOutOfBoundsException (l'elenco è ancora vuoto)

when(spy.get(0)).thenReturn("foo");

// Devi usare doReturn () per lo stub: doReturn("foo").when(spy).get(0);

2. Sostituzione di una precedente eliminazione di eccezioni:

when(mock.foo()).thenThrow(new RuntimeException());

// Impossibile: il metodo foo () basato sull'eccezione viene chiamato in modo da generare RuntimeException. when(mock.foo()).thenReturn("bar");

// Devi usare doReturn () per lo stub:

doReturn("bar").when(mock).foo(); Gli scenari sopra mostrano un compromesso dell'elegante sintassi di Mockito. Tuttavia, gli scenari sono molto rari. Lo spionaggio dovrebbe essere sporadico e prevalente la soppressione delle eccezioni è molto rara. Per non parlare del fatto che in generale l'eccesso di stub è un potenziale odore di codice che evidenzia troppi stub.

Continuando questa risposta , c'è un'altra differenza che se si desidera che il metodo restituisca valori diversi, ad esempio quando viene chiamato per la prima volta, viene chiamato per la seconda volta ecc., È possibile passare valori, ad esempio ...

PowerMockito.doReturn(false, false, true).when(SomeClass.class, "SomeMethod", Matchers.any(SomeClass.class));

Quindi restituirà false quando il metodo viene chiamato nello stesso caso di test e quindi restituirà nuovamente false e infine true.

Quest'ultima alternativa è usata per i metodi sulle beffe che ritornano void.

Dai un'occhiata, ad esempio, qui: Come rendere mock to void i metodi con mockito