Un po 'confuso sulle differenze tra framework Mock come NMock e VS 2011 Fakes Framework. Passando attraverso MSDN, quello che capisco è che i Fakes ti permettono di deridere le tue dipendenze proprio come RhinoMock o NMock, tuttavia l'approccio è diverso, Fakes genera codice per ottenere questa funzionalità ma il framework Mocks no. Quindi la mia comprensione è corretta? Fakes è solo un altro framework Mock
Risposte:
La tua domanda riguardava il modo in cui il framework MS Fakes è diverso da NMock e sembra che le altre risposte abbiano risolto alcuni di questi problemi, ma qui ci sono alcune informazioni in più su come sono gli stessi e come sono diversi. NMock è anche simile a RhinoMocks e Moq, quindi li sto raggruppando con NMock.
Ci sono 3 differenze principali che vedo subito tra NMock / RhinoMocks / Moq e MS Fakes Framework:
Il framework MS Fakes utilizza codice generato, molto simile a Accessors nelle versioni precedenti di Visual Studio invece di tipi generici. Quando si desidera utilizzare il framework falsi per una dipendenza, aggiungere l'assembly che contiene la dipendenza ai riferimenti del progetto di test e quindi fare clic con il pulsante destro del mouse su di esso per generare i doppi di test (stub o shim). Quindi, quando esegui il test, stai effettivamente utilizzando invece queste classi generate. NMock utilizza generici per realizzare la stessa cosa (cioè IStudentRepository studentRepository = mocks.NewMock<IStudentRepository>()). A mio parere, l'approccio del framework MS Fakes inibisce la navigazione del codice e il refactoring dall'interno dei test poiché stai effettivamente lavorando su una classe generata, non sulla tua vera interfaccia.
Il framework MS Fakes fornisce stub e talpe (shim), mentre NMock, RhinoMocks e Moq forniscono tutti stub e mock . Non capisco davvero la decisione di MS di non includere i mock e io personalmente non sono un fan dei nei per i motivi descritti di seguito.
Con il framework MS Fakes, fornisci un'implementazione alternativa dei metodi che desideri stub. All'interno di queste implementazioni alternative, è possibile specificare i valori restituiti e tenere traccia delle informazioni su come o se il metodo è stato chiamato. Con NMock, RhinoMocks e Moq, si genera un oggetto fittizio e quindi si utilizza quell'oggetto per specificare i valori di ritorno stub o per tenere traccia delle interazioni (se e come sono stati chiamati i metodi). Trovo l'approccio dei falsi alla SM più complesso e meno espressivo.
Per chiarire la differenza in ciò che forniscono i framework: NMock, RhinoMocks e Moq forniscono tutti due tipi di doppioni di test (stub e mock). La struttura dei falsi fornisce mozziconi e talpe (li chiamano spessori) e sfortunatamente non include simulazioni. Per comprendere le differenze e le somiglianze tra NMock e MS Fakes, è utile capire quali sono questi diversi tipi di doppi di test:
Stub: gli stub vengono utilizzati quando è necessario fornire valori per metodi o proprietà che verranno richiesti ai doppi di test dal metodo sottoposto a test. Ad esempio, quando il mio metodo sottoposto a test chiama il metodo DoesStudentExist () del doppio di test IStudentRepository, voglio che restituisca true.
L'idea degli stub nei falsi NMock e MS è la stessa, ma con NMock faresti qualcosa del genere:
Stub.On(mockStudentRepository).Method("DoesStudentExist").Will(Return.Value(true));
E con MSFakes faresti qualcosa di simile:
IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository() // Generated by Fakes.
{
DoesStudentExistInt32 = (studentId) => { return new Student(); }
};
Si noti nell'esempio di MS Fakes che si crea un'implementazione completamente nuova per il metodo DoesStudentExist (si noti che si chiama DoesStudentExistInt32 perché il framework fakes aggiunge i tipi di dati dei parametri ai nomi dei metodi quando genera gli oggetti stub, penso che questo offuschi la chiarezza di i test). Ad essere onesti l'implementazione di NMock mi infastidisce anche perché usa una stringa per identificare il nome del metodo. (Perdonatemi se ho frainteso come si intende usare NMock.) Questo approccio inibisce davvero il refactoring e per questo motivo consiglio vivamente RhinoMocks o Moq su NMock.
Mock: i mock vengono utilizzati per verificare l'interazione tra il metodo sottoposto a test e le sue dipendenze. Con NMock, lo fai impostando aspettative simili a questa:
Expect.Once.On(mockStudentRepository).Method("Find").With(123);
Questo è un altro motivo per cui preferirei RhinoMocks e Moq su NMock, NMock utilizza il vecchio stile di aspettativa mentre RhinoMocks e Moq supportano entrambi l'approccio Arrange / Act / Assert in cui specifichi le interazioni previste come affermazioni alla fine del test come questo :
stubStudentRepository.AssertWasCalled( x => x.Find(123));
Ancora una volta, nota che RhinoMocks usa un lambda invece di una stringa per identificare il metodo. Il framework ms fakes non fornisce affatto mock. Ciò significa che nelle implementazioni bloccate (vedere la descrizione degli stub sopra) devi impostare le variabili che successivamente verifichi siano state impostate correttamente. Sarebbe simile a questo:
bool wasFindCalled = false;
IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository()
{
DoesStudentExistInt32 = (studentId) =>
{
wasFindCalled = true;
return new Student();
}
};
classUnderTest.MethodUnderTest();
Assert.IsTrue(wasFindCalled);
Trovo che questo approccio sia un po 'complicato poiché devi tenere traccia della chiamata nello stub e quindi affermarla più avanti nel test. Trovo che gli esempi NMock, e in particolare RhinoMocks, siano più espressivi.
Talpe (Shims): Ad essere sincero, non mi piacciono le talpe, a causa del loro potenziale uso improprio. Una delle cose che mi piacciono così tanto del test unitario (e del TDD in particolare) è che il test del codice ti aiuta a capire dove hai scritto codice scadente. Questo perché è difficile testare un codice scritto male. Questo non è vero quando si usano le talpe perché le talpe sono effettivamente progettate per consentire di testare dipendenze che non vengono iniettate o per testare metodi privati. Funzionano in modo simile agli stub, tranne per il fatto che usi un ShimsContext come questo:
using (ShimsContext.Create())
{
System.Fakes.ShimDateTime.NowGet = () => { return new DateTime(fixedYear, 1, 1); };
}
La mia preoccupazione con gli spessori è che le persone inizieranno a vederli come "un modo più semplice per test unitari" perché non ti obbliga a scrivere codice nel modo in cui dovresti. Per un resoconto più completo su questo concetto, guarda questo mio post:
Per ulteriori informazioni su alcune preoccupazioni relative ai framework falsi, dai un'occhiata a questi post:
Se sei interessato a imparare RhinoMocks, ecco un video di formazione Pluralsight (divulgazione completa - ho scritto questo corso e vengo pagato le royalty per le visualizzazioni, ma penso che si applichi a questa discussione, quindi lo includo qui):
Hai ragione, ma c'è di più nella storia. Le cose più importanti da togliere da questa risposta sono:
La tua architettura dovrebbe fare un uso corretto degli stub e dell'iniezione di dipendenza, piuttosto che fare affidamento sulla stampella di Fakes e mock
I falsi e i mock sono utili per testare il codice che non dovresti o non puoi modificare, come ad esempio:
Shims (noto come "Moles", durante lo sviluppo) è effettivamente un quadro beffardo che funziona tramite chiamate deviate. Invece di costruire faticosamente una simulazione (sì, anche usare Moq è relativamente doloroso!), Gli shim usano semplicemente l'oggetto codice di produzione già in atto. Gli shim semplicemente reindirizzano la chiamata dalla destinazione di produzione al delegato di test.
Gli stub vengono generati dalle interfacce nel progetto di destinazione. L'oggetto Stub è proprio questo: un'implementazione dell'interfaccia. Il vantaggio dell'utilizzo del tipo Stub è che puoi generare rapidamente uno stub senza ingombrare il tuo progetto di test con molti stub di utilizzo una tantum, per non parlare del tempo perso per crearli. Ovviamente, dovresti comunque creare stub concreti, da utilizzare in molti test.
L'implementazione efficiente di Fakes (tipi di Shims, Mock e Stub) richiede un po 'di tempo per abituarsi, ma ne vale la pena. Ho risparmiato personalmente settimane di tempo di sviluppo, utilizzando i tipi Shims / Mole, Mocks e Stub. Spero che ti diverta con la tecnologia quanto me!
A quanto ho capito, il team di Visual Studio voleva evitare di competere con le varie librerie fittizie disponibili per .NET. La SM deve spesso affrontare decisioni difficili come questa. Vengono bloccati se non forniscono determinate funzionalità ("perché MS non ci fornisce una libreria fittizia; i mock sono un requisito così comune?") E dannati se lo fanno ("perché Microsoft agisce in modo così aggressivo e sostenitori naturali fuori mercato? ") Molto spesso, ma non sempre, decidono di trattenersi dal fornire semplicemente la propria alternativa alle tecnologie disponibili e ben accolte. Questo sembra essere il caso qui.
La funzione di spessore di Fakes è davvero molto utile. Certo, ci sono pericoli. Ci vuole un po 'di disciplina per assicurarti di usarlo solo dove necessario. Tuttavia, colma una grande lacuna. La mia lamentela principale è che viene fornito solo con l'edizione Ultimate di VS 2012 e quindi sarà disponibile solo per una sottosezione della comunità di sviluppo .NET. Che peccato.
Fakes include due diversi tipi di oggetti "falsi". Il primo, chiamato "stub", è essenzialmente un dummy generato automaticamente il cui comportamento predefinito può (e di solito sarebbe) essere sovrascritto per renderlo un mock più interessante. Tuttavia, mancano alcune delle funzionalità offerte dalla maggior parte dei framework di mocking attualmente disponibili. Ad esempio, se si desidera verificare che sia stato richiamato un metodo su un'istanza stub, è necessario aggiungere la logica per questo da soli. Fondamentalmente, se stai creando manualmente i tuoi mock ora, gli stub probabilmente sembrerebbero un miglioramento. Tuttavia, se stai già utilizzando un framework di derisione più completo, potresti sentire che mancano alcuni pezzi importanti dagli stub Fakes.
L'altra categoria di oggetti offerta da Fakes, chiamata "shim", espone un meccanismo per sostituire il comportamento delle dipendenze che non sono state (o non possono essere) disaccoppiate adeguatamente per la sostituzione standard tramite mock. AFAIK, TypeMock è l'unico dei principali framework di mocking che attualmente offre questo tipo di funzionalità.
A proposito, se hai già provato Moles, Fakes è essenzialmente la stessa cosa, finalmente uscendo da Microsoft Research e trasformandosi in un prodotto reale.
Per quanto riguarda gli oggetti Fake (Shim + Stub), è stato ben definito sopra, anche se credo che l'ultimo paragrafo dell'ultimo commento riassuma abbastanza bene l'intera situazione.
Sebbene molte persone sosterranno che gli oggetti falsi (Shim + Stub) sono buone risorse da avere in alcuni casi di unit test, lo svantaggio è che non importa se stai usando Visual Studio 2012 o Visual Studio 2013, queste opzioni sono SOLO disponibili con le versioni Premium o Ultimate. IOW, questo significa che NON dovrai eseguire NESSUNO di quei falsi (Shim + Stub) su nessuna versione Pro.
Probabilmente potresti vedere l'opzione di menu Fakes (Shim + Stub) nelle versioni Pro, ma attenzione, ci sono alcune probabilità piuttosto elevate che non finirai con assolutamente nulla ... Non genererà alcun errore di compilazione che ti dice che qualcosa di importante manca, le opzioni non ci sono, quindi non perdere tempo ...
È un fattore importante da considerare in un team di sviluppo, specialmente se uno è l'unico che utilizza la versione Ultimate mentre tutti gli altri usano la versione Pro ... Moq d'altra parte può essere facilmente installato tramite Nuget indipendentemente dalla versione di Visual Studio che usi. Non ho avuto problemi a usare Moq, la chiave con qualsiasi strumento è sapere a cosa servono e come usarli correttamente;)