2010-05-13 14 views
60

Sono un pioniere delle attività di test delle unità presso la mia azienda e ho bisogno di scegliere un quadro di derisione da utilizzare. Non ho mai usato una struttura di derisione prima. Abbiamo già scelto Google Test, quindi usare Google Mock sarebbe bello. Tuttavia, le mie impressioni iniziali dopo guardando Google Mock's tutorial sono:Google Mock è un buon punto di partenza?

  • La necessità di ri-dichiarare ogni metodo nella classe beffardo con una macro MOCK_METHODn sembra inutile e sembra andare contro il principio DRY.
  • I loro corrispondenti (ad esempio, il '_' in EXPECT_CALL (tartaruga, Avanti (_));) e l'ordine di corrispondenza sembrano quasi troppo potenti. Ad esempio, sarebbe facile dire qualcosa che non vuoi dire e perdere bug in quel modo.

Ho molta fiducia negli sviluppatori di google e poca fiducia nella mia capacità di giudicare gli schemi di derisione, non li ho mai usati prima. Quindi la mia domanda è: Sono questi problemi validi?

Oppure non esiste un modo migliore per definire un oggetto fittizio e gli abbinamenti sono intuitivi da utilizzare nella pratica? Apprezzerei le risposte di chiunque abbia utilizzato Google Mock in precedenza e i confronti con altri framework C++ sarebbero utili.

+7

Per la parte "redeclaring", si noti che 'gmock_gen.py' in genere può scrivere il mock per te (dato il file di intestazione e la classe base come input). Dato che C++ è complesso, potrebbe rovinarsi, ma ciò continuerà a coprire la maggior parte degli scenari di utilizzo, quindi accelera le cose. –

+0

Grazie. Sfortunatamente, dubito che la gente qui lo userebbe. Potrei provare, comunque. – des4maisons

risposta

43

Lo uso spesso.

È banale fare cose relativamente semplici e fare cose molto difficili - è praticamente ciò che voglio da un framework.

La parte più difficile della scrittura di Matcher personalizzati (e altre cose) con i mock di Google non è il mock di Google, sono gli errori del modello di C++ ... sono quasi impossibili da analizzare. Scrivo spesso espressioni complesse sviluppando progressivamente un'espressione di lavoro da alcune espressioni meno complicate. In questo modo, gli errori del modello sono più facili da individuare.

Non ho visto un'opzione migliore per il C++ beffeggiamento, e Google copre un sacco di argomenti, quindi ti suggerisco di fare un tentativo.

WRT il principio ASCIUTTO, sono d'accordo nel dichiarare i metodi derisori sfortunati, ma senza riflessione, non sono sicuro che C++ avrebbe molta fortuna altrimenti. Sono quasi certo che se ci fosse un modo, googlemock lo userebbe;)

BTW: Il googlemock cookbook è un buon riferimento.

+0

Grazie per il feedback, non l'avrei ottenuto dal tutorial! – des4maisons

+0

riguardo a DRY, vedere la mia risposta a una domanda riguardante la gestione della generazione del codice boilerplate per i mock: http://stackoverflow.com/a/10260532/170521 – lurscher

+4

Ho anche deciso di andare con google google. Inizialmente, pensavo che il più grande svantaggio è che devi scrivere esplicitamente una classe di simulazione (con le macro DEFINE_METHODXXX). Tuttavia, ho scoperto che esiste uno script python incluso nel pacchetto che può generare la classe mock per te. – hopia

14

Disclaimer: Ho scritto HippoMocks.

Posso consigliare altri quadri di derisione; c'è una classe che non ti fa ripetere te stesso. Inoltre, eliminano una nuova sintassi per la corrispondenza, facendo in modo che il codice venga letto molto più come C++ combinato con l'inglese. Provaci!

http://www.assembla.com/wiki/show/hippomocks

+0

Grazie, darò un'occhiata a questo. – des4maisons

+1

Quindi, qualche conclusione? – Michael

+1

Non è necessario creare una classe di simulazione separata è una funzione così bella! –

19

Fake-It è un semplice quadro di scherno per C++. FakeIt utilizza le ultime funzionalità di C++ 11 per creare un'API espressiva (ma molto semplice). Con FakeIt non è necessario ripetere i metodi né creare una classe derivata per ogni falso. Ecco come Fake-It:

struct SomeInterface { 
    virtual int foo(int) = 0; 
}; 

// That's all you have to do to create a mock. 
Mock<SomeInterface> mock; 

// Stub method mock.foo(any argument) to return 1. 
When(Method(mock,foo)).Return(1); 

// Fetch the SomeInterface instance from the mock. 
SomeInterface &i = mock.get(); 

// Will print "1" 
cout << i.foo(10); 

Non ci sono molte altre caratteristiche da esplorare. Vai avanti e give it a try.

6

Ho usato googletest + googlemock professionalmente per alcuni anni e mi piace decisamente. Una cosa che non è stata menzionata da altri è che se sei già impegnato ad usare googletest allora ha molto senso usare anche googlemock. Sono abbastanza ben integrati e condividono uno stile e una filosofia di design simili, il che è bello.

Ad esempio, googlemock fornisce i macro ASSERT_THAT() che sono super-utili e coesistono piacevolmente con le asserzioni dei googletest.

Vorrei tuttavia avvertirti di abusare del potere di googlemock. Può essere estremamente allettante per scrivere molto complessi & abbinamenti potenti che finiscono per essere totalmente illeggibili. Devi solo essere disciplinato quando lo usi.

Alcuni altri pensieri:

  • Googlemock può avere una curva di apprendimento piuttosto ripida; la complessità degli incontri e delle aspettative non è così semplice come si potrebbe sperare.
  • La preoccupazione relativa alla violazione di DRY è valida; è fastidioso dover definire manualmente i mock quando sembra che possano essere facilmente generati automaticamente. È abbastanza comune per i team scrivere i propri generatori di codice che definiscono automaticamente googlemocks per le loro interfacce.
Problemi correlati