2012-06-25 19 views
5

È facile verificare che un'interazione specifica (chiamata di metodo specifica) si sia verificata su un oggetto fittizio in Mockito e che sia presente verifyZeroInteractions() per verificare che non si siano verificate affatto interazioni. Supponiamo che sto testando un'interfaccia come quella di un logger, con metodi come info(), warn(), error() ecc. In uno specifico scenario, so che uno di questi metodi dovrebbe essere chiamato, ma non mi interessa davvero quale. Esiste un modo compatto per verificare che qualsiasi interazione con l'oggetto fittizio si sia verificata senza la necessità di specificare quale metodo esattamente dovrebbe essere chiamato? O forse un tale meccanismo non è necessario perché "il modo Mockito" di testare questo sarebbe diverso da quello che immagino?È possibile verificare l'interazione arbitraria usando Mockito in modo compatto?

risposta

1

Se è possibile esternalizzare la creazione del proprio oggetto logger dalla classe sottoposta a test, non c'è motivo per cui non è possibile scrivere la propria implementazione di test dell'interfaccia di registro che registrerà quali metodi sono stati esercitati e li ha iniettati come parte di la tua configurazione di prova.

Le librerie di simulazioni fanno molto bene, ma a volte ci sono casi d'angolo come quelli che hai trovato dove potrebbero non coprire le tue esigenze.

Se si scrive una propria implementazione per testare in questo modo, e iniettare in yourt classe di test in prova, allora si può affermare sul getCount() > 0

public class LoggerTestSupportImpl implements ILogger { 

    private int count = 0; 

    @Override 
    public int getCount() { 
     return count; 
    } 

    @Override 
    public void info(String message) { 
     count++;  
    } 

    @Override 
    public void warn(String message) { 
     count++;  
    } 
} 
+1

Questo è esattamente come ho testato la mia classe finora, Mi stavo chiedendo se Mockito potesse risparmiarmi di scrivere le banali implementazioni per tutti i metodi. –

+0

Direi che hai fatto la cosa sensata Michal. Mockito non supporta questo tipo di test. La tua unica scelta è quella di andare giù per la rotta 'ArgumentCaptor' come menzionato da Kevin, ma questo porta a un sacco di" rumore "nelle tue classi di test. – Brad

+0

Concordato che è un po 'rumoroso, ma la maggior parte del rumore è localizzata nelle dichiarazioni e nel metodo Before, e si può persino aggiungere il Captor alle dichiarazioni di livello di classe se deve essere utilizzato su più metodi di test (non è nemmeno necessario se non si accede a msgs) . La cosa bella dell'utilizzo di Mockito è che hai già accesso all'API di registrazione completa. Per fare ciò nel tuo esempio devi espandere le capacità del tuo mock arrotolato a mano (catturare/recuperare # arbitrario dei messaggi registrati, ecc.) Ma per esigenze semplici la tua strada sembra più semplice, più pulita, * e * riutilizzabile, quindi quelle sono alcuni vantaggi per il tuo approccio. –

2

Con log4j, per testare il logger che faccio la seguente configurazione:

@Mock private Appender log4jAppender; 
private Logger logger; 

@Before 
public void setup() { 
    MockitoAnnotations.initMocks(this); 

    Logger root = Logger.getRootLogger(); 
    if (!root.getAllAppenders().hasMoreElements()) { 
     // No appenders means log4j is not initialized! 
     BasicConfigurator.configure(); 
    } 
    logger = Logger.getLogger(MyClassWhichLogs.class); 
    logger.addAppender(log4jAppender); 
} 

e poi nel mio test faccio la seguente:

verifyZeroInteractions(log4jAppender); 

o

verify(log4jAppender).doAppend(any(LoggingEvent.class); 

Se è necessario testare i valori registrati, è invece possibile fornire un rilevatore:

ArgumentCaptor<LoggingEvent> logCaptor = ArgumentCaptor.forClass(LoggingEvent.class); 
verify(log4jAppender).doAppend(logCaptor.capture()); 
assertTrue(logCaptor.getValue().contains("my text to match"); 

Sebbene questo non risponda necessariamente alla domanda generalizzata (non penso che esista ciò che stai cercando), potrebbe risolvere questo problema specifico per il test della registrazione.

Problemi correlati