Riutilizzo di Mock / Stub come specifica di prova

Question

Riutilizzo di Mock / Stub come specifica di prova

#1 da (2 voti)
#2 da (1 voti)

4

Usiamo simulazioni per garantire che un test unitario sia eseguito solo contro il codice che dovrebbe essere testato. Ciò impedisce che un errore in un modulo A causi il fallimento di test di un modulo dipendente B. Tuttavia, ora dobbiamo anche testare l'interazione in modo esplicito. Non è sufficiente che A e B siano di per sé verdi, A deve funzionare come B lo prevede, e B deve avere le giuste aspettative.

Ora, le aspettative di B sono già formalmente definite: nei mock e negli stub. Se ho uno stub in cui A restituisce determinati output per determinati input, ciò significa che mi aspetto che sia possibile avere A in uno stato in cui mostra questo comportamento.

Quindi, invece di scrivere lunghi test di integrazione, devo solo impostare un A e testarlo contro gli stub e i mock che ci sono già. Oppure, per capovolgerlo, posso usare un'istanza reale di A per verificare la correttezza dei miei mock.

Funziona in pratica? Esistono best practice (ad esempio, a chi appartengono questi test di pseudo-integrazione, se la suite di test di A fornisse già alcuni mock che potrebbero essere usati)? Questo è possibile anche con i famosi framework di simulazione?

unit-testing mocking

posta Cephalopod 26.07.2012 - 16:47

fonte

2 risposte

1

Does this work in practice?

Può, ma il problema arriva nel creare un'istantanea della finta. Spesso l'integrazione che stai testando è una sorta di risoluzione dell'istanza che gira e incolla i vari pezzi; o gli script di implementazione. Se la cambi in modo da far ruotare i mock, hai violato il test.

Quindi dipende principalmente dal tuo scenario specifico. Non c'è niente di particolarmente sbagliato nel riutilizzo come pratica generale qui.

risposta data 26.07.2012 - 22:30

fonte

Leggi altre domande sui tag unit-testing mocking

Come vengono implementate le eccezioni asincrone? Gestione delle transazioni nidificate .NET

score 2 · Accepted Answer

Se comprendo correttamente la tua domanda, vuoi testare l'integrazione senza integrarla. Considero che i mock e gli stub e i falsi e così via dovrebbero essere usati per controllare l'input e l'output indiretti e per testare correttamente il comportamento quando necessario. Questo è ciò che Gerard Meszaros dice in xTest di test di unità: codice di test di refactoring .

Se avessi una classe A e una classe B userei i mock per testarli separatamente, esattamente come hai specificato.

Tuttavia, un test di integrazione dovrebbe esercitare entrambi gli oggetti. I test di integrazione dovrebbero solo coprire i percorsi che portano alla comunicazione tra gli oggetti. Queste comunicazioni dovrebbero accadere, per davvero. Quello che suggerisci non è proprio giusto per i test di integrazione. È fattibile da un punto di vista tecnico, ma non è giusto dal punto di vista del livello di test che vuoi fare.

Ovviamente, puoi prendere in giro, fermare, fingere, ecc. tutte le classi D, E, F ... Z necessarie per inizializzare A e B. In alcune situazioni più complesse, puoi anche parzialmente prendere in giro A e B, quindi che alcuni metodi restituiranno quello che vuoi senza fare tonnellate di calcoli, ma le parti che comunicano tra le due classi dovrebbero rimanere reali, sempre.