2013-02-15 17 views
9

Ho appena iniziato a leggere Professional Test Driven Development with C#: Developing Real World Applications with TDDComprensione di tronchi, falsi e finte.

Ho difficoltà a capire matrici, falsi e derisioni. Da quello che ho capito finora, sono oggetti falsi usati allo scopo di testare i tuoi progetti unitari e che un finto è uno stub con la logica condizionale in esso.

Un'altra cosa che penso di aver raccolto è che i mock sono in qualche modo legati all'iniezione di dipendenze, un concetto che sono riuscito a capire solo ieri.

Quello che non capisco è perché li utilizzerei davvero. Non riesco a trovare esempi concreti online che li spieghino correttamente.

Qualcuno può spiegarmi questo concetto?

+2

Leggi questo http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html e questo http://martinfowler.com/articles/mocksArentStubs.html – blank

+1

E già che ci sei si potrebbe anche leggere questo http://www.mockobjects.com/files/mockrolesnotobjects.pdf – blank

+0

Spero che tu possa perdonare lo spot, ma abbiamo scritto un intero libro "Growing Object Oriented Software", che indirizza la motivazione per usando i mock. –

risposta

19

Come ho letto in passato, qui è quello che credo ogni termine è sinonimo di

Stub

Qui si sta spegnendo il risultato di un metodo per un valore noto, solo per lasciare che il il codice funziona senza problemi. Ad esempio, supponiamo di avere il seguente:

public int CalculateDiskSize(string networkShareName) 
{ 
    // This method does things on a network drive. 
} 

Non ti interessa quale sia il valore di ritorno di questo metodo, non è rilevante. Inoltre potrebbe causare un'eccezione se eseguita se l'unità di rete non è disponibile. Pertanto, il risultato viene annullato al fine di evitare potenziali problemi di esecuzione con il metodo.

così si finisce per fare qualcosa di simile:

sut.WhenCalled(() => sut.CalculateDiskSize()).Returns(10); 

falso

con una finta si sta tornando di dati falsi, o la creazione di un'istanza di un oggetto falso. Un classico esempio sono le classi di repository. Prendi questo metodo:

public int CalculateTotalSalary(IList<Employee> employees) { } 

Normalmente il metodo precedente sarebbe passato una raccolta di dipendenti che sono stati letti da un database. Tuttavia nei test di unità non si desidera accedere a un database. Così si crea un falso elenco dipendenti:

IList<Employee> fakeEmployees = new List<Employee>(); 

È quindi possibile aggiungere elementi fakeEmployees e affermare i risultati attesi, in questo caso lo stipendio totale.

Mocks

Quando si utilizzano oggetti mock si intendono verificare alcuni comportamenti, o di dati, su quegli oggetti mock. Esempio:

si desidera verificare che un metodo specifico è stato eseguito durante una corsa di prova, ecco un esempio generico utilizzando Moq quadro beffardo:

public void Test() 
{ 
    // Arrange. 
    var mock = new Mock<ISomething>(); 

    mock.Expect(m => m.MethodToCheckIfCalled()).Verifiable(); 

    var sut = new ThingToTest(); 

    // Act. 
    sut.DoSomething(mock.Object); 

    // Assert 
    mock.Verify(m => m.MethodToCheckIfCalled()); 
} 

Speriamo che quanto sopra aiuta a chiarire le cose un po '.

EDIT: Roy Osherove è un noto sostenitore di Test Driven Development, e ha alcune ottime informazioni sull'argomento.Si può trovare molto utile:

http://artofunittesting.com/

+0

molto informativo. Ho sempre pensato che i falsi e le finte fossero intercambiabili. Imparo cose nuove ogni giorno qui :) +1 – bas

+0

cosa c'è 'm' in Mock? ed è ISomething la classe che stiamo testando? – fersarr

+0

Il 'm' è un parametro che viene passato alla funzione' Expect() '. È un'espressione lambda. Non è dichiarato da nessuna parte, esiste semplicemente all'interno del 'Expect()' lambda. 'var mock = new Mock ();' significa che stai creando un oggetto che implementa 'ISomething', quindi' ISomething' è un'interfaccia, non un oggetto. Puoi quindi usare 'mock' per controllare come i metodi rispondono quando vengono chiamati, ad esempio tramite la funzione' Expect() '. –

0

manuale di questa unità PHP mi ha aiutato molto come introduzione:

"A volte è semplicemente difficile per testare il sistema in prova (SUT) perché dipende su altri componenti che non possono essere utilizzati nell'ambiente di test, poiché potrebbero non essere disponibili, non restituiscono i risultati necessari per il test o perché l'esecuzione di questi avrebbe effetti collaterali indesiderati. In altri casi, la nostra strategia di test richiede per avere più controllo o visibilità del comportamento interno del SUT. " Più: https://phpunit.de/manual/current/en/test-doubles.html

e trovo meglio "introduzioni" quando alla ricerca di "prova raddoppia", come prende in giro, falsi, alberi mozzi e gli altri sono noti.

3

Sono tutte varianti del Test Double. Ecco un buon riferimento che spiega le differenze tra loro: http://xunitpatterns.com/Test%20Double.html

Inoltre, dal post di Martin Fowler: http://martinfowler.com/articles/mocksArentStubs.html

Meszaros utilizza il duplice criterio termine come il termine generico per ogni tipo di finta oggetto usato al posto di un oggetto reale a scopo di test. Il nome deriva dalla nozione di una controfigura nei film. (Uno dei suoi obiettivi era di evitare di usare qualsiasi nome che è stato già ampiamente utilizzata.) Meszaros poi definiti quattro particolari tipi di doppio:

  1. oggetti dummy: sono passati in giro, ma mai effettivamente utilizzati. Di solito sono sono appena usati per riempire gli elenchi dei parametri.
  2. Gli oggetti falsi in realtà hanno implementazioni funzionanti, ma di solito prendono alcuni collegamenti che rendono non adatti alla produzione (un database in memoria è un buon esempio ).
  3. Gli stub forniscono risposte predefinite alle chiamate effettuate durante il test, di solito non risponde affatto a qualcosa che non sia quello programmato in per il test. Gli stub possono anche registrare informazioni sulle chiamate, come , uno stub gateway email che ricorda i messaggi "inviati", o forse solo il numero di messaggi "inviati".
  4. I mazzi sono ciò di cui stiamo parlando qui: oggetti preprogrammati con aspettative che formano una specifica delle chiamate che dovrebbero ricevere.

Di questi tipi di doppi, solo i finti insistono sulla verifica del comportamento. Gli altri doppi possono, e solitamente lo fanno, utilizzare la verifica dello stato. I Mazzi in realtà si comportano come gli altri doppi durante la fase di esercitazione, come hanno bisogno di far credere al SUT che stia parlando con i suoi veri collaboratori .