Come si eseguono i test unitari? Bandiere del compilatore? Librerie statiche?

Question

Sono appena iniziato con TDD e sono curioso di sapere quali approcci gli altri prendono per eseguire i loro test. Per riferimento, sto usando il framework di test di google, ma credo che la domanda sia applicabile alla maggior parte degli altri framework di testing e alle lingue diverse da C/C++.

mio approccio generale finora è stato di fare una delle tre cose:

1. Scrivi la maggior parte delle applicazioni in una libreria statica, quindi creare due file eseguibili. Un eseguibile è l'applicazione stessa, mentre l'altro è il test runner con tutti i test. Entrambi collegano alla libreria statica.

2. Incorporare il codice di test direttamente nell'applicazione stessa e abilitare o disabilitare il codice di test utilizzando i flag del compilatore. Questo è probabilmente l'approccio migliore che ho usato finora, ma riordina un po 'il codice.

3. Incorporare il codice di test direttamente nell'applicazione stessa e, in base a determinati parametri della riga di comando, eseguire l'applicazione stessa o eseguire i test incorporati nell'applicazione.

Nessuna di queste soluzioni sono particolarmente eleganti ...

Come si fatto?

Answer 1

Tendo a preferire le librerie statiche su DLL, quindi la maggior parte del mio codice C++ finisce comunque in librerie statiche e, come hai trovato, sono facili da testare come DLL.

Per il codice che genera in un exe, ho un progetto di test separato che include semplicemente i file di origine che sono in fase di test e che sono in genere incorporati nell'exe OPPURE creare una nuova libreria statica che contiene la maggior parte degli exe e testarlo nello stesso modo in cui collaudo tutte le mie altre librerie statiche. Trovo che di solito prendo l'approccio "più codice in una biblioteca" con nuovi progetti e il "richiama i file di origine dal progetto exe nell'approccio del progetto di test" quando eseguo i test retrospettivi su applicazioni esistenti.

Non mi piacciono affatto le opzioni 2 e 3. Gestire le configurazioni di build per 2 è probabilmente più difficile che avere un progetto di test separato che richiama semplicemente le fonti di cui ha bisogno e che includa tutti i test nell'exe come suggerito in 3 è solo sbagliato;)

Answer 2

Sto usando un test-runner di terze parti con il loro framework e includendo test in script di build. I test sono al di fuori del codice di produzione (dll esterno).

Answer 3

L'approccio n. 1 è il modo in cui l'ho sempre fatto in C/C++ e Java. La maggior parte del codice dell'applicazione si trova nella libreria statica e cerco di mantenere al minimo la quantità di codice aggiuntivo necessario per l'applicazione.

Il modo in cui approccio TDD in Python e altri linguaggi dinamici è leggermente diverso in quanto lascio il codice sorgente per l'applicazione e test in giro e un corridore di test trova i test e li esegue.

Answer 4

Io uso due approcci, per le DLL basta collegare i miei test di unità con la DLL, facile. Per i file eseguibili includo i file sorgente che vengono testati sia nel progetto eseguibile che nel progetto di test unitario. Questo aggiunge leggermente al tempo di compilazione, ma significa che non ho bisogno di separare l'eseguibile in una lib statica e una funzione principale.

Uso boost.test per il test dell'unità e cmake per generare i file di progetto e trovo questo l'approccio più semplice. Sto anche introducendo lentamente i test unitari su una grande base di codice legacy, quindi sto provando a introdurre il minor numero di modifiche, nel caso in cui io disturbo gli altri sviluppatori e li scoraggi dai test delle unità. Mi preoccuperei che l'uso di una libreria statica solo per il test delle unità potrebbe essere visto come una scusa per non adottarlo.

Detto questo, ritengo che l'approccio alla libreria statica sia particolarmente utile se si sta partendo da zero.

Answer 5

Per le applicazioni C/C++ cerco di avere il maggior numero possibile di codice in una o più DLL, con l'applicazione principale che rappresenta il minimo indispensabile per l'avvio e la distribuzione della DLL. Le DLL sono molto più facili da testare perché possono esportare tutti i punti di ingresso che mi piacciono per un'applicazione di test da utilizzare.

Uso un'applicazione di test separata che collega alla/e Dll.Sono fortemente a favore del mantenimento del codice di test e del codice "prodotto" in moduli separati.

Answer 6

vado dal numero 1, alcuni motivi sono

• Permette di verificare che ogni link lib correttamente
• non si vuole codice aggiuntivo nel prodotto
• E 'più facile per eseguire il debug individuale piccola programmi di test
• Si possono avere bisogno di più eseguibili per alcuni test (come test di comunicazione)

per C++ costruire e testare, ho piace usare CMake che può eseguire una selezione degli eseguibili di destinazione come test e stampare un riepilogo dei risultati.

Answer 7

Persino, io uso un altro approccio che si basa un po 'sul tuo:

Mantengo intatto il progetto. Se è un eseguibile, dovrebbe rimanere un eseguibile. È sufficiente creare un'azione di post-generazione per aggregare tutti i file obj in una libreria statica.

Quindi, è possibile creare il progetto di test, collegando il framework di test e la libreria statica generata in precedenza.

Ecco alcuni argomenti corrispondenti alla vostra domanda:

• Visual Studio C++: Unit test exe project with google test?
• Linker error - linking two "application" type projects in order to use Google Test