Test unitario: dovremmo preoccuparci di distinguere tra Mock e Stub?

Questa domanda su SO dà una buona comprensione sulla differenza di ciascuno. È sottile ma è ancora lì. In brevi tronconi sono muti, serie di risposte preregistrate per un test specifico. Di solito non sono molto riutilizzabili e sono solo plug di base per testare una classe specifica. I mazzi sono più intelligenti perché puoi configurarli dinamicamente e interrogarli in seguito sulle interazioni a cui sono stati sottoposti alla classe testata.

Ottenere questo diritto è importante se il tuo team usa entrambi per usi specifici. Scambiare i termini in queste condizioni porterà ad una certa confusione sull'attività richiesta: "Stub this class with limit data per il test" implica per me un test diverso da "deridere le dipendenze per il test". Nei primi stub restituiscono stupidamente valori falsi che mi permetteranno di testare valori specifici. il secondo implica che devo anche testare le interazioni tra la classe testata e le sue dipendenze. Nulla mi impedisce però di implementare gli stub con la stessa struttura beffarda (creando effettivamente un muto mock) ma è molto più difficile creare un mock da uno stub.

Ciò detto, nSubstitute sembra risolvere questo problema fondendo tutti i concetti sotto un unico indirizzo. A quel punto il dibattito è praticamente accademico.

Grazie per il link: -)

Martin Fowler ha un grande articolo sull'argomento " I mock non sono stub " ma non dice perché dovresti aver cura.

Karl Seguin ha un'opinione molto strong: " Smetti di usare i mock " (Leggi i commenti anche per una discussione migliore)

In conclusion, by their very nature, mocks are all about testing interactions. This doesn't decrease coupling like most think. There's actually no way to create greater coupling than to us a mock - because you have to specify every possible detail of each interaction. When you want to test interactions, which you should test, use a mock. But I guarantee you that the ratio of behavioral tests to interaction tests will be in the neighborhood of 5 to 1. Which means mocks should be in the minority. When you can, you should always favor either stubs or the real implementation. I haven't talked about using the real implementation (again, something the .NET community avoids like a plague), but hopefully you can see how even that isn't as crazy an idea as you've been told.

Darren Cauthon ha risposto a Karl Seguin: " Smetti di usare Mock - A Rebuttal "

Quello che prendo da questa discussione, sì, dovresti averne cura. La scelta influisce sulla fragilità dei test, sul modo in cui i test mostrano l'intento e se i test sono corretti.

Penso che valga la pena di fare un piccolo sforzo in più. Se gli stub vengono utilizzati per gli input e i mock per le uscite, i test sono più chiaramente leggibili. Come ulteriore vantaggio si potrebbe scoprire che alcuni oggetti dovrebbero essere mock e stub (usati per input e output) che potrebbero indicare un'architettura / design insufficiente. Secondo me questo è vero nella mia area (controllo integrato della climatizzazione), ma questo potrebbe dipendere dall'area in cui lavori.