2014-06-24 14 views
5

Sto provando a convertire alcuni dei miei test di unità dall'uso di JMock all'utilizzo di Mockito e ho riscontrato alcuni ostacoli.Mockito vs JMock

Innanzitutto nel mio test utilizzando JMock la verifica e ritorno dello stub avvenire in un solo passo come segue

contextMockery.checking(new Expectations() {{ 
     oneOf(dateUtilityService).isBeforeToday(URGENT_DATE); 
      will(returnValue(true)); 
    }}); 

Ciò verifica essenzialmente che il metodo viene chiamato e restituisce un valore fisso allo stesso tempo. Il test fallisce se il metodo isBeforeToday NON viene chiamato e restituisce il mio valore predefinito di true allo stesso tempo. Mentre quando si utilizza Mockito devo verificare che il metodo viene chiamato e poi tornare il mio valore in scatola in fasi distinte, che sono più o meno un duplicato come segue:

doReturn(true).when(dateUtilityService).isBeforeToday(URGENT_DATE); 
    verify(dateUtilityService).isBeforeToday(URGENT_DATE); 

Non c'è un modo per fare questo in un solo passo?

In secondo luogo, se dimentico di elencare una chiamata di metodo a uno dei miei mock nelle mie aspettative, JMock non supera il test con "eccezione di invocazione imprevista" che a mio avviso è corretta mentre Mockito passerà felicemente il test a meno che non verifichi esplicitamente che una chiamata al metodo non deve mai accadere, è corretto (sembra sbagliato)? C'è un modo per dire a mockito di fallire il test se vengono fatte chiamate di metodo inaspettate alle mie dipendenze derise?

+0

Solo per curiosità, ha fatto prendere in considerazione anche la conversione dei test per JMockit? La sintassi è molto più vicina a jMock: 'new Expectations() {{dateUtilityService.isBeforeToday (URGENT_DATE); risultato = vero; }}; '. –

risposta

5

1.

Quando si stub un metodo chiamare il metodo di verifica di solito non è necessario - si dovrebbe verificare l'azione in base al valore di ritorno (nel tuo caso qualcosa potrebbe accadere o qualcosa verrà restituito quando i rendimenti dateUtilityService vero - verificare che, invece di verificare l'interazione con una finta

documentazione

Mockito parla anche di questo http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html#2

2.

questo porta in realtà a.. test fragili e non è consigliato il modo di fare le cose con il mockito. Ecco perché non c'è modo di impostare questo comportamento.

Vedi http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html#8

+0

In alcuni casi questo ha senso (come quello che ho mostrato) quando lo stub sta cambiando un valore sul tipo di ritorno. Ma come ho detto nella mia seconda parte della mia domanda, se mi dimentico di interrompere una chiamata al metodo (che potrebbe non cambiare alcun valore di ritorno) nel mio test, mi piacerebbe saperlo in modo che io possa fare una scelta concisa a entrambi interrompere la chiamata o dire al test che non dovrebbe mai essere chiamato. –

+1

@ClintonBosch È possibile aggiungere una chiamata a 'verifyNoMoreInteractions()' alla fine del metodo di test, per rilevare le chiamate non interrotte. –

+0

Da quando ho iniziato a usare Mockito (ho usato JMock dal 2007 o anche prima ... non ricordo), ho notato test verdi in cui i colleghi si sono dimenticati di chiamare il collaboratore, ho sentito frasi come "test unitari qualche volta ti danno il falso positivo , è meglio avere test di integrazione ". Forse, è meglio usare uno strumento come JMock e cercare di evitare quei "test fragili" in un altro modo invece di usare strumenti di progettazione così deboli come Mockito. – sixro