Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

EasyMock by Mind Map: EasyMock
0.0 stars - 0 reviews range from 0 to 5

EasyMock

alcuni temi che potrebbero interessare

qual'e' la filosofia dietro all'expect()?

come fare per "rilassare" il controllo dell'interazione coi mock?

cosa sono i nice mock?

differenze tra nice, normal e strict mock

testare le eccezioni dei collaboratori

devo mettere sempre la verify alla fine del test?

features di EasyMock

il paradigma record-replay

dopo la sua creazione (e prima della replay), un mock e' in stato "record", ovvero, registra il comportamento programmato, tiene traccia delle chiamate ai suoi metodi

dopo la replay, il mock e' nello stato replay, ovvero, controlla che i metodi programmati siano chiamati con i parametri attesi, e in caso di mismatch segnala l'errore, "Unexpected method call ...", controlla se ci sono chiamate a metodi non programmati, e in tal caso segnala l'errore, "Unexpected method call ..."

la verifica del comportamento atteso

la verify() alla fine del test serve a verificare che i metodi programmati siano stati effettivamente chiamati, "Expectation failure on verify ..."

come specificare i valori di ritorno

per i metodi di un mock che non tornano void si deve usare il metodo expect() per la programmazione della chiamata al metodo, e andReturn() per programmare il valore di ritorno

testare la gestione delle eccezioni

per le checked exceptions (Throwable) si puo' usare il metodo andThrow() sulla expect() del mock

per le unchecked exceptions (es: RuntimeException) usa sempre andThrow(), su tutti i metodi dei mock

quante volte e' usata la andThrow nei progetti BIT?, 12 volte

la programmazione di un numero atteso di chiamate ad un metodo

si usa il metodo times(n) sulla expect() del mock

per definire interazioni complesse con i collaboratori

di solito e' una feature poco usata, quante volte avete usato times()?, zero

rilassare il conto delle chiamate

alternative a times() per avere un vincolo meno stringente sul numero di chiamate ad un metodo, atLeastOnce(), usato 2 volte nei progetti BIt, anyTimes(), usato 3 volte nei progetti BIt

mock piu' stringente

strict mock, verifica il rispetto dell'esatto ordine dei metodi programmato sul mock, si crea con EasyMock.createStricMock()

mock meno stringente

nice mock, consente di invocare qualunque metodo del mock senza doverlo programmare, ma per i valori di ritorno, torna i default (es: null, 0, false, ...), si crea con EasyMock.createNiceMock()

Argument Matchers

per verificare la corrispondenza tra un metodo atteso sul mock e quello attuale, EasyMock applica la equals() sui parametri del metodo

gli argument matchers consentono di definire un proprio criterio di match sugli parametri dei metodi programmati sul mock, esempio classico: il parametro e' un array, come faccio, non posso definire la equals!, uso l'argument matcher predefinito aryEq(), ne esistono alcuni built-in, anyObject(), e' un ArgumentMatcher che torna sempre true, usato molto nei test dei dao-price..., aryEq(), anyBoolean(), anyInt(), anyDouble(), ..., se ne possono creare di "custom" estendendo l'interfaccia IArgumentMatcher, unico difetto: se si decide di usare gli argument matcher, si devono usare per tutti i parametri del metodo

utili quando non si vuole o non si puo' usare la equals come criterio di match dei parametri

riuso dei mock

con la reset()

definire un metodo stub

consente di programmare delle chiamate ai metodi di un mock, senza che EasyMock controlli come e quante volte sono chiamate effettivamente

asStub(), sui metodi void

andStubReturn(), sui metodi che ritornano un valore

andStubThrow()

altre features minori

andAnswer(), per creare valori di ritorno del mock

note e osservazioni

la expect() si deve usare solo quando il metodo programmato sul collaboratore ritorna qualcosa

altrimenti basta invocare il metodo del collaboratore

la replay() supporta varargs, e senza argomenti fa la replay su tutti i mock del test case

devo mettere sempre la verify alla fine del test?

sempre meglio metterla, anzi, ancora meglio sarebbe metterla in un metodo tearDown eseguito alla fine del test

a meno che in un particolare test non interessa verificare la corretta interazione con i collaboratori ma solo avere dei mock programmati opportunamente

per avere un messaggio di errore piu' parlante, conviene implementare la toString degli oggetti che sono parametri di un metodo mock

si puo' usare ToStringCreator di spring

quando si vuole testare una eccezione

invece di fare, @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); }

@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); } }, permette di verificare l'esatta eccezione lanciata dal mock

nota a margine della mia esplorazione

tanto codice "abbandonato", per es in, IPODataServiceAggregatorTest.java, SingleRowDaoTest, ParameterLessSingleRowDaoTest, IntradayDaoImplTestMock, FundsControllerUnitTest, test Etf Etfs Intraday Returns Correct View And Populate Model, per gli amanti della shell, find . -iname "*.java" | xargs egrep -i "//" | egrep -v "Auto-generated method stub" | wc -l, 19 linee su CWS-LSE, 157 su CWS-BIt, 511 su kernel-dao-ipo, 648 su kernel-dao-price-bit, 2009 su tutti i progetti kernel-* che ho scaricato in locale (me ne mancano alcuni), find kernel-* -iname "*.java" | xargs egrep -i "//" | egrep -v "Auto-generated method stub" | wc -l, IdemIntradayAggregatorTest, la classe sotto test ha tre collaboratori, ma nel test ne sono usati solo due

esempi sul progetto

IdemIndexFutureBasketDaoImplUnitTest

CompanySearchDataServiceImplTest