1. note e osservazioni
1.1. la expect() si deve usare solo quando il metodo programmato sul collaboratore ritorna qualcosa
1.1.1. altrimenti basta invocare il metodo del collaboratore
1.2. la replay() supporta varargs, e senza argomenti fa la replay su tutti i mock del test case
1.3. devo mettere sempre la verify alla fine del test?
1.3.1. sempre meglio metterla
1.3.1.1. anzi, ancora meglio sarebbe metterla in un metodo tearDown eseguito alla fine del test
1.3.2. a meno che in un particolare test non interessa verificare la corretta interazione con i collaboratori ma solo avere dei mock programmati opportunamente
1.4. per avere un messaggio di errore piu' parlante, conviene implementare la toString degli oggetti che sono parametri di un metodo mock
1.4.1. si puo' usare ToStringCreator di spring
1.5. quando si vuole testare una eccezione
1.5.1. invece di fare
1.5.1.1. @Test(expected = IfsException.class) public void testIfsThrowsAnException() throws Exception { // va bene se non mi interessa controllare l'eccezione lanciata dal collaboratore all'oggetto sotto test expect(mockIfsTemplate.execute(callback, mapper)).andThrow(new CommunicationException("test")); replay(mockIfsTemplate); dao.getIdemIndexFutureBasket(REAL_TIME_PROFILE); }
1.5.2. @Test public void testIfsThrowsAnException_WithTryCatch() throws Exception { CommunicationException expectedException = new CommunicationException("test"); expect(mockIfsTemplate.execute(callback, mapper)).andThrow(expectedException); replay(mockIfsTemplate); try { dao.getIdemIndexFutureBasket(REAL_TIME_PROFILE); fail(expectedException + " should have been thrown!"); } catch (CommunicationException actualException) { assertEquals(expectedException, actualException); } }
1.5.2.1. permette di verificare l'esatta eccezione lanciata dal mock
1.6. nota a margine della mia esplorazione
1.6.1. tanto codice "abbandonato"
1.6.1.1. per es in
1.6.1.1.1. IPODataServiceAggregatorTest.java
1.6.1.1.2. SingleRowDaoTest
1.6.1.1.3. ParameterLessSingleRowDaoTest
1.6.1.1.4. IntradayDaoImplTestMock
1.6.1.1.5. FundsControllerUnitTest
1.6.1.2. per gli amanti della shell
1.6.1.2.1. find . -iname "*.java" | xargs egrep -i "//" | egrep -v "Auto-generated method stub" | wc -l
1.6.1.3. IdemIntradayAggregatorTest
1.6.1.3.1. la classe sotto test ha tre collaboratori, ma nel test ne sono usati solo due
2. esempi sul progetto
2.1. IdemIndexFutureBasketDaoImplUnitTest
2.2. CompanySearchDataServiceImplTest
3. alcuni temi che potrebbero interessare
3.1. qual'e' la filosofia dietro all'expect()?
3.2. come fare per "rilassare" il controllo dell'interazione coi mock?
3.2.1. cosa sono i nice mock?
3.3. differenze tra nice, normal e strict mock
3.4. testare le eccezioni dei collaboratori
3.5. devo mettere sempre la verify alla fine del test?
4. features di EasyMock
4.1. il paradigma record-replay
4.1.1. dopo la sua creazione (e prima della replay), un mock e' in stato "record"
4.1.1.1. ovvero
4.1.1.1.1. registra il comportamento programmato
4.1.1.1.2. tiene traccia delle chiamate ai suoi metodi
4.1.2. dopo la replay, il mock e' nello stato replay
4.1.2.1. ovvero
4.1.2.1.1. controlla che i metodi programmati siano chiamati con i parametri attesi
4.1.2.1.2. controlla se ci sono chiamate a metodi non programmati
4.2. la verifica del comportamento atteso
4.2.1. la verify() alla fine del test serve a verificare che i metodi programmati siano stati effettivamente chiamati
4.2.1.1. "Expectation failure on verify ..."
4.3. come specificare i valori di ritorno
4.3.1. per i metodi di un mock che non tornano void si deve usare il metodo expect() per la programmazione della chiamata al metodo
4.3.1.1. e andReturn() per programmare il valore di ritorno
4.4. testare la gestione delle eccezioni
4.4.1. per le checked exceptions (Throwable) si puo' usare il metodo andThrow() sulla expect() del mock
4.4.2. per le unchecked exceptions (es: RuntimeException) usa sempre andThrow(), su tutti i metodi dei mock
4.4.3. quante volte e' usata la andThrow nei progetti BIT?
4.4.3.1. 12 volte
4.5. la programmazione di un numero atteso di chiamate ad un metodo
4.5.1. si usa il metodo times(n) sulla expect() del mock
4.5.2. per definire interazioni complesse con i collaboratori
4.5.3. di solito e' una feature poco usata
4.5.3.1. quante volte avete usato times()?
4.5.3.1.1. zero
4.6. rilassare il conto delle chiamate
4.6.1. alternative a times() per avere un vincolo meno stringente sul numero di chiamate ad un metodo
4.6.1.1. atLeastOnce()
4.6.1.1.1. usato 2 volte nei progetti BIt
4.6.1.2. anyTimes()
4.6.1.2.1. usato 3 volte nei progetti BIt
4.7. mock piu' stringente
4.7.1. strict mock
4.7.1.1. verifica il rispetto dell'esatto ordine dei metodi programmato sul mock
4.7.1.2. si crea con EasyMock.createStricMock()
4.8. mock meno stringente
4.8.1. nice mock
4.8.1.1. consente di invocare qualunque metodo del mock senza doverlo programmare
4.8.1.2. ma per i valori di ritorno, torna i default (es: null, 0, false, ...)
4.8.1.3. si crea con EasyMock.createNiceMock()
4.9. Argument Matchers
4.9.1. per verificare la corrispondenza tra un metodo atteso sul mock e quello attuale, EasyMock applica la equals() sui parametri del metodo
4.9.2. gli argument matchers consentono di definire un proprio criterio di match sugli parametri dei metodi programmati sul mock
4.9.2.1. esempio classico: il parametro e' un array
4.9.2.1.1. come faccio, non posso definire la equals!
4.9.2.1.2. uso l'argument matcher predefinito aryEq()
4.9.2.2. ne esistono alcuni built-in
4.9.2.2.1. anyObject()
4.9.2.2.2. aryEq()
4.9.2.2.3. anyBoolean(), anyInt(), anyDouble()
4.9.2.2.4. ...
4.9.2.3. se ne possono creare di "custom" estendendo l'interfaccia IArgumentMatcher
4.9.2.4. unico difetto: se si decide di usare gli argument matcher, si devono usare per tutti i parametri del metodo
4.9.3. utili quando non si vuole o non si puo' usare la equals come criterio di match dei parametri
4.10. riuso dei mock
4.10.1. con la reset()
4.11. definire un metodo stub
4.11.1. consente di programmare delle chiamate ai metodi di un mock, senza che EasyMock controlli come e quante volte sono chiamate effettivamente
4.11.2. asStub()
4.11.2.1. sui metodi void
4.11.3. andStubReturn()
4.11.3.1. sui metodi che ritornano un valore
4.11.4. andStubThrow()
4.12. altre features minori
4.12.1. andAnswer()
4.12.1.1. per creare valori di ritorno del mock