Si utilizza un ritorno stub per una chiamata di metodo sul mock che si prevede che si verifichi ma non è altrimenti interessato. Si utilizza un ritorno normale per una chiamata di metodo "normale".
Si consideri il seguente metodo:
public void someMethod(String arg) {
if (logger.isDebugEnabled()) {
logger.debug("Calling doSomething() on service "
+ service.getName().hashCode());
}
service.postMessage("{" + arg + "}");
if (logger.isDebugEnabled()) {
logger.info("Finished calling doSomething() on service "
+ service.getName().hashCode());
}
}
... dove service
è un campo mockable. La cosa hashCode()
nelle istruzioni del registro è inventata, ma il punto è che il tuo mock deve rispondere a un numero qualsiasi di chiamate a getName()
per evitare un NPE, mentre altrimenti non ci si potrebbe importare di meno.
Quando si scrive un test di unità basata EasyMock per questo metodo, ci si andStubReturn()
la chiamata a getName()
e utilizzare un normale andReturn()
per la chiamata a postMessage(String)
. Quando si verifica l'oggetto fittizio, verrà preso in considerazione solo quest'ultimo e il test non si interromperà se si modifica la configurazione di log4j.
quindi fammi vedere se ho capito bene. Fondamentalmente andStubReturn() è usato per metodi che non ci interessano per il nostro test per gli oggetti mock, ma siamo tenuti a prendere in giro il ritorno altrimenti, il codice non funzionerà. I metodi andStubReturn() non sono verificati da EasyMock; mentre i metodi andReturn() sono verificati. – Glide
Questo è corretto. – Barend
Ciao, sarà lo stesso usare eReturn() con expectLastCall(). AnyTimes()? – damluar