Quali sono i fattori chiave nella scelta di un Mocking Framework?

Sto cercando di iniziare con gli oggetti nei miei test unitari. Sembra che ci siano tonnellate di buoni quadri beffardi là fuori.

1. I diversi framework hanno destinatari diversi?
2. Quali fattori devo considerare quando scelgo quale quadro è giusto per la mia situazione?

I diversi framework hanno destinatari diversi?

Sì. Alcuni framework come Microsoft Moles , TypeMock Isolator e JustMock , ti permettono di essere in grado di deridere qualsiasi cosa. Questi strumenti beffardi sono generalmente migliori per gli sviluppatori che vogliono usarli su un codice legacy esistente poiché potrebbe non essere possibile eseguire il refactoring in un progetto più testabile. *

Tradizionalmente, i progetti testabili significano che la base di codice deve fare un uso liberale di interfacce, classi astratte, metodi virtuali, classi non sigillate, ecc. Pertanto, i framework di derisione tradizionali come Moq e RhinoMocks funzionano bene con il codice sviluppato usando Test Driven Development, Dependency Injection e altri concetti simili. A proposito, ti consiglio vivamente di utilizzare Dependency Injection poiché ottieni molto più di un semplice codice testabile, ma anche di un codice più gestibile.

Quali fattori devo considerare quando scelgo quale quadro è giusto per la mia situazione?

• Attività di sviluppo. Strumenti come Moq e RhinoMocks sono molto attivi e popolari e quindi aggiornati.
• Open Source vs. Commerciale . Considera i vari pro e contro tipici di questo confronto. Costo, supporto, ecc ...
• Scadenza. Quanto è nuovo lo strumento. È in beta (come Microsoft Moles) o ha avuto diverse versioni stabili? Ad esempio, mi piacciono le talpe per il codice legacy, ma ci sono diversi bug che devono essere risolti al suo interno e ci vorrà molto prima che vengano risolti (prossima versione novembre 2011).
• Documentazione. Esistono diversi libri e blog che trattano test di unità, derisione, auto-derisione, ecc. Inoltre, quanto è buona la documentazione dello strumento?
• Sintassi . Ogni strumento ha il suo modo di dire la stessa cosa. Scopri quale è più adatto a te.
• Velocità . Gli strumenti che utilizzano la profilatura CLR (TypeMock, Moles, JustMock) possono essere molto più lenti di quelli tradizionali (Moq, RhinoMocks). Questa penalità può essere un problema in quanto accumuli molti test unitari. La regola empirica è che se un test richiede più di 1/10 di secondo è troppo lento.
• Supporto comunitario . Altri sviluppatori stanno scrivendo altri strumenti che si estendono (o funzionano in complimento) allo strumento beffardo? Esiste un progetto Moq.Contrib che aggiunge un'abilità di derisione automatica a Moq (che aiuta ad accelerare i tempi di scrittura dei test). Meglio ancora, c'è AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks, che consente anche Auto-derisione, oltre alla creazione di variabili anonime.

^{* Vedi Lavorare in modo efficace con il codice legacy , per i modi su come refactificare lentamente il codice senza test in codice che può essere utilizzato con gli strumenti di test (e derisione) tradizionali.}

Il tutorial di Moq ha una sezione sullo sfondo, la filosofia e le controversie proprio all'inizio che ne discute in relazione ad alcuni strumenti specifici: TypeMock Isolator, RhinoMocks e Moq. È scritto per spiegare Moq, quindi è naturalmente un po 'distorto, ma l'ho trovato abbastanza utile per me quando ho cercato di capire alcune delle differenze nei framework beffardi.

Ho trovato utili anche le risposte a questa discussione SO su C # Mocking Frameworks . La maggior parte si riferisce solo a un Mocking Framework che l'utente trova davvero utile, ma c'è una risposta da parte di HaraldV che discute di simulazioni basate su proxy e simulazioni basate su profiler.

Sono stato anche in grado di trovare una tabella comparativa online. Si noti che è del 2009, quindi non sono sicuro che sia aggiornato; c'è almeno un commento che afferma che le informazioni su TypeMock e callback sono obsolete, ma il grafico potrebbe essere utile per sollevare problemi da considerare anche se sarà necessario fare legwork per vedere quale sia lo stato attuale: RhinoMocks, Moq, NMock, e tabella di confronto TypeMock

Esiste un progetto su Google Code con casi di test in più framework di derisione per un facile confronto del codice: mocking-frameworks-compare

1. Facilità d'uso. Alcuni framework hanno idiomi di utilizzo più avanzati. Ad esempio, MOQ consente l'uso di lambda per codificare le aspettative. Alcune librerie meno recenti non lo supportano.
2. Velocità. Ogni test unitario dovrebbe essere veloce in modo che l'intera libreria non richieda ore per essere eseguita. Alcuni framework di derisione hanno simulazioni generate staticamente, il che è veloce. Altri framework generano dinamicamente codice in fase di runtime, che è più lento.
3. Supporto. Volete un framework che sia attivamente supportato da correzioni e aggiornato per supportare le nuove versioni di .NET, man mano che vengono rilasciate.
4. Energia. La maggior parte dei quadri beffardi che ho studiato sono all'incirca gli stessi in termini di potere. C'è un'eccezione notevole. Microsoft Moles consente di deridere "metodi non virtuali / statici in tipi sigillati". Questo è qualcosa che nessun altro framework beffardo supporta, per quanto ne sappia.

Nel mio team, abbiamo scelto Microsoft Moles . Vince in modo significativo su # 2, # 3 e # 4, anche se è meno idiomatico della maggior parte delle alternative ed è di fascia bassa su # 1.