Come fare per organizzare un test harness unità per eredità codice Visual C ++?

Question

Ho un progetto di Visual Studio 2005, C ++, si tratta di un'applicazione console.

Voglio iniziare a ricevere bit del codice sotto un test harness, ma ho incontrato alcuni problemi che non so come migliore impugnatura.

Non voglio che la maggior parte del mio codice di prova per finire nel exe normale in produzione così ho pensato che sarebbe stato meglio per creare un progetto separato per i miei test. Prima edizione, come è questo nuovo progetto sta per chiamare nel resto del codice? Devo fare il mio codice legacy un lib o .dll con un unico punto di accesso e creare un progetto separato che chiama il principale del mio codice legacy?

Devo andare per il brutto hack di mettere tutti i miei test nei file che sono interamente #ifdef TESTING in modo che il codice non finisca nel mio exe produzione? Se sì, come dovrei condizionalmente caricare il framework di test? Utilizzare una configurazione delle proprietà separata per il test?

Sono fondamentalmente alla ricerca di qualche suggerimento su come fare per ottenere un test harness su un progetto legacy exe in Visual C ++

Answer 1

In primo luogo, vi consiglio vivamente il libro di Michael Feather "Lavorare in modo efficace con il codice legacy" . E 'tutto su come aggiungere unit test automatizzati per un'applicazione legacy che non ha le prove. Se vi state chiedendo "come faccio nemmeno iniziare a testare questo mucchio di codice", allora questo libro è per voi.

Michael è anche l'autore di CppUnit, un framework open source di test NUnit-come per il codice C ++. Lo si può trovare qui: http://sourceforge.net/projects/cppunit/ .

Un modo rapido-and-dirty per aggiungere test è quello di aggiungere una configurazione unittest alla soluzione. Questa configurazione compilare il codice, ma invece di collegare al vostro Main.cpp, si esclude la vostra main.cpp dalla costruzione e comprendono UnitTestMain.cpp, dove si sarebbe posizionare le chiamate per eseguire i test di unità. Abbiamo iniziato in questo modo molto tempo fa, quando non sapevamo niente di meglio. Si finisce per spendere un sacco di tempo includendo ed escludendo tutti i vari moduli testMyCode.cpp alle varie configurazioni, però, e diventa stancante dopo un po '. Abbiamo scoperto che gli sviluppatori non piace questo approccio troppo.

Un approccio molto migliore è quello di aggiungere un progetto di test di unità alla soluzione, con una dipendenza sviluppare il vostro vero e proprio progetto. Se il progetto si chiama Foo.vcproj, lo chiamano Foo_test.vcproj. Questo progetto contiene solo il tuo codice di prova, è # include le intestazioni Foo, e si collega ai vostri moduli compilati fooCode.obj. Aggiungere una chiamata per eseguire Foo_test.exe come un post-generazione passo della costruzione Foo_test, ed esegue automaticamente i test di unità durante la compilazione. Se i test falliscano, la compilazione fallisce. Se avete gated-check-in configurati sul server di build, nessuno può controllare nei cambiamenti che si rompono test esistenti.

Answer 2

Penso che avere la maggior parte del codice che viene testato in una biblioteca è la cosa migliore, ma non necessariamente pratico in tutti i casi.

Una soluzione è quella di avere una configurazione progetto separato (ad esempio, Debug, di uscita e di prova) e avere il vostro codice di prova in file separati che sono contrassegnati come "esclusi da costruire" sotto il Debug e Release configurazioni. È possibile avere il codice semplice di avviare i test all'interno di un #ifdef o di avere una versione stub del test runner che è incluso nella non-Test costruisce.

Un'altra opzione (anche se è piuttosto hack-ish) è di avere il codice di prova fuga da WinMain e il tuo codice di produzione fuga da regolare vecchi main. Quando si crea utilizzando il "Windows" sottosistema i test verrà eseguito, e quando si genera per il sottosistema Console vostro codice di produzione verrà eseguito. Non so fuori mano se il linker cadere le funzioni di test non-chiamata dalla generazione di produzione, però.