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

I diversi quadri hanno diversi target di pubblico?

Sì. Alcuni framework come Microsoft Moles , TypeMock Isolator e JustMock , ti permettono di essere in grado di prendere in giro qualsiasi cosa. Questi strumenti di derisione sono generalmente migliori per gli sviluppatori che desiderano utilizzarli su un codice legacy esistente poiché potrebbe non essere possibile rifattorizzarli in un progetto più verificabile. *

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

Quali fattori dovrei prendere in considerazione quando scelgo quale struttura è adatta alla mia situazione?

• Attività di sviluppo. Strumenti come Moq e RhinoMocks sono molto attivi e popolari e quindi aggiornati.
• Vs Open Source. Commerciale . Considera i vari pro e contro tipici di questo confronto. Costo, supporto, ecc.
• Maturità. Quanto è nuovo lo strumento. È in versione beta (come Microsoft Moles) o ha avuto diverse versioni stabili? Ad esempio, mi piace Moles per il codice legacy, ma ci sono diversi bug che devono essere affrontati in esso e ci sarà da attendere prima che vengano indirizzati (prossima release, novembre 2011).
• Documentazione. Esistono diversi libri e blog che coprono il test delle unità, il mocking, l'auto-mocking, ecc. Inoltre, quanto è buona la documentazione dello strumento?
• Sintassi . Ogni strumento ha il suo modo di dire la stessa cosa. Scopri quale ti è più adatto.
• Velocità . Gli strumenti che usano il profiling CLR (TypeMock, Moles, JustMock), possono essere molto più lenti di quelli tradizionali (Moq, RhinoMocks). Questa penalità di velocità può essere un problema in quanto si accumulano molti test unitari. La regola generale è che se un test richiede più di 1/10 al secondo, è troppo lento.
• Supporto della community . Gli altri sviluppatori stanno scrivendo altri strumenti che estendono (o lavorano in complimento) allo strumento di simulazione? Esiste un progetto Moq.Contrib che aggiunge un'abilità Auto-mocking a Moq (che aiuta ad accelerare la scrittura di test tempo). Meglio ancora, c'è AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks, che consente anche Auto-mocking, oltre alla creazione di variabili anonime.

^{* Vedi Funzionante in modo efficace con il codice legacy , per informazioni su come eseguire lentamente il refactoring del codice senza test in codice che può essere utilizzato con strumenti di test tradizionali (e di simulazione)}

Il tutorial Moq ha una sezione sullo sfondo, filosofia e polemica all'inizio che discute questo in relazione ad alcuni strumenti specifici: TypeMock Isolator, RhinoMocks e Moq. È stato scritto per spiegare Moq, quindi è naturalmente un po 'distorto, ma ho trovato che fosse molto utile per me quando cercavo di capire alcune delle differenze nei framework di simulazione.

Ho trovato le risposte a questo SO thread su C # Mocking Frameworks anche utile. La maggior parte si riferisce solo a un Mocking Framework che l'utente trova davvero utile, ma c'è una risposta da HaraldV un modo in cui discute mock basati su proxy e mock basati sui profiler.

Sono stato anche in grado di trovare una tabella di confronto 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 non sono aggiornate, ma il grafico potrebbe essere utile per sollevare problemi da considerare anche se è necessario eseguire legwork per vedere quale sia lo stato corrente: tabella di confronto RhinoMocks, Moq, NMock e TypeMock

Esiste un progetto su Google Code con casi di test in più quadri di simulazione per un facile confronto tra i codici: mocking-frameworks-compare

1. Facilità d'uso. Alcuni dei framework hanno idiomi d'uso più avanzati. Ad esempio, MOQ consente l'utilizzo di lambda per codificare le aspettative. Alcune librerie più vecchie non supportano questo.
2. Velocità. Ogni test di unità dovrebbe essere veloce in modo che l'intera libreria non impieghi ore per essere eseguita. Alcune strutture di derisione hanno simulazioni generate in modo statico, che è veloce. Altri framework generano dinamicamente il codice in fase di runtime, che è più lento.
3. Supporto. Volete un framework che sia attivamente supportato con correzioni e aggiornato per supportare nuove versioni di .NET, man mano che vengono rilasciate.
4. Potenza. La maggior parte delle strutture di derisione che ho studiato sono più o meno le stesse in termini di potenza. C'è un'eccezione notevole. Microsoft Moles consente la simulazione di "metodi non virtuali / statici in tipi sigillati". Questo è qualcosa che nessun'altra struttura di derisione supporta, per quanto ne so.

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 e si trova nella fascia bassa al primo posto.