Beffardo metodi non-virtuali in C ++ senza modificare il codice di produzione?

Question

Sono un abbastanza nuovo sviluppatore di software attualmente lavorando aggiungendo unit test per un progetto esistente C ++ che ha iniziato anni fa. A causa di un motivo non tecnico, non mi è permesso di modificare qualsiasi codice esistente. La classe di base di tutti i miei moduli ha un sacco di metodi per impostare / ottenere i dati e comunicare con altri moduli.

Dato che voglio solo unità di test di ogni singolo modulo, voglio essere in grado di utilizzare i valori in scatola per tutti i miei metodi di comunicazione tra i moduli. Cioè per un metodo di Ping (), che controlla se un altro modulo è attivo, voglio avere è restituire true o false in base a quale tipo di prova che sto facendo. Ho cercato in Google prova e Google Mock, e lo fa sostengo beffardo metodi non-virtuali. Tuttavia il metodo descritto ( http://code.google.com/p/googlemock/ wiki / CookBook # Mocking_Nonvirtual_Methods ) mi impone di "templatize" i metodi originali per prendere sia in oggetti reali o finte. Non posso andare e templatize miei metodi nella classe di base a causa della necessità accennato in precedenza, quindi ho bisogno di qualche altro modo di scherno questi metodi virtuali

In sostanza, i metodi voglio deridere sono in qualche classe base, i moduli voglio unit test e creare mock di derivano classi di detta classe di base. Ci sono moduli intermedi tra la mia classe di modulo base e dei moduli che voglio provare.

Gradirei qualche consiglio!

Grazie,

JW

modificare: a esempi più concreti

La mia classe di base è diciamo rootModule, il modulo che voglio testare è leafModule. V'è un modulo intermedio che eredita da rootModule, leafModule eredita da questo modulo intermedio.

Nel mio leafModule, voglio provare il metodo doStuff (), che chiama il GetStatus non virtuale (moduleName) definito nella classe rootModule. Ho bisogno di fare in qualche modo GetStatus () per restituire un valore in scatola prescelta. Mocking è nuovo per me, così sta usando gli oggetti mock anche il giusto approccio?

Answer 1

vorrei scrivere uno script Perl / Rubino / Python per leggere nell'albero dei sorgenti originali e scrivere un albero dei sorgenti beffato in una directory diversa. Non è necessario analizzare pienamente C ++ per sostituire una definizione di funzione.

Answer 2

Ci sono alcuni modi diversi di sostituzione di funzioni non virtuali. Uno è quello di ri-dichiarare e compilare un nuovo eseguibile di prova per ogni diversa serie di funzioni non virtuali che desideri testare. Non è certo scalabile.

Una seconda opzione è quella di renderli virtuali per il test. La maggior parte dei compilatori consentono di definire qualcosa sulla riga di comando in modo da compilare il codice con -DTEST_VIRTUAL = virtuale o -DTEST_VIRTUAL per renderli sia virtuale o normale a seconda se sia o non sia in prova oppure no.

Una terza opzione che può essere utilizzabile è quello di utilizzare un quadro di scherno che consente funzioni non virtuali finte. Sono l'autore di HippoMocks (esclusione di responsabilità per quanto riguarda la neutralità e così via) e di recente abbiamo aggiunto la possibilità di prendere in giro le funzioni C puro su piattaforme x86. Questa può essere estesa a funzioni membro non virtuali con un po 'di lavoro e sarebbe quello che stai cercando. Tenete presente che, se il compilatore può vedere sia l'uso e la definizione di una funzione in una sola volta che essa può inline e che la beffarda potrebbe non riuscire. Ciò vale in particolare per le funzioni che sono definite nelle intestazioni.

Se regolare funzione C beffardo è sufficiente per voi, è possibile utilizzarlo come è ora.

Answer 3

Un approccio potrebbe essere quello di specificare le fonti diverse per i test. Di 'la tua target di produzione utilizza rootModule.h e rootModule.cpp. Utilizzare fonti diverse per il vostro target di test. È possibile specificare una diversa intestazione per cambiare il vostro percorso di inclusione, in modo che #include "rootModule.h" in realtà carica unittest / rootModule.h. Poi rootModule finto al contenuto del vostro cuore.