Come mantenere le impostazioni per i moduli di test dell'unità C ++ in sincronia con i moduli del codice di produzione?

• Nota: provengo da uno sfondo Windows / Visual-C ++.
• Nota: ho già letto l'articolo di Michael Feathers Funzionante in modo efficace con Legacy Codice .
• Nota: Ampia domanda, chiedendo risposte ristrette , cioè anche se non voglio limitare questa domanda a uno specifico compilatore / piattaforma / sistema, le risposte utili conterranno probabilmente solo una combinazione.

Il modello di sviluppo C ++

Anche idealmente, hai i tuoi file sorgente ben organizzati:

• Klass1.h / cpp
• Klass2.h / cpp
• CustomAlgorithms.h (solo intestazione)
• main.cpp (potrebbe non essere necessario per un modulo lib dyn / static)

Quindi, l'applicazione è composta da moduli n (anche se sono solo librerie statiche collegate tutte insieme a un modulo eseguibile alla fine.

Per ottenere dai moduli sorgente ai moduli binari, è necessario disporre di file di progetto / creare file o altro. Questi file "dicono" al compilatore (e al linker) come generare i moduli binari dal codice sorgente.

Aggiunta dei test delle unità

Indipendentemente dal Framework di test che utilizzi e indipendentemente da dove inserisci il tuo codice di test, devi produrre moduli binari diversi / aggiuntivi per il tuo codice di test che per il tuo codice di produzione . (Almeno per qualsiasi eseguibile o libreria dinamica, le librerie statiche dovrebbero essere un po 'più semplici.)

Se hai bisogno di produrre diversi moduli binari per il tuo codice di test, allora devi mantenere un insieme separato / aggiuntivo di impostazioni (del compilatore) per questo codice di prova .

Con Visual Studio puoi provare a ridurre al minimo la quantità di lavoro utilizzando i file vsprops, ma ti rimane un file di progetto separato per i tuoi test e i tuoi moduli di produzione. Questo può diventare problematico da mantenere.

Con un sistema make, non sono sicuro di come sia fatto, ma desidero esplicitamente che questa domanda comprenda entrambi, poiché le tecniche da uno possono tradurre nell'altro.

Quindi, TL; DR , come ti impedisci di dover modificare manualmente due diversi "file di progetto" (uno per il test, uno per la produzione), ogni volta che aggiungi o modifichi qualcosa in le impostazioni di produzione. (*)

_{(*) Potresti pensare di non cambiare le cose spesso, ma di pensare a un progetto su scala reale con dozzine (centinaia) di moduli e dozzine di sviluppatori. Ogni piccola quantità di lavoro manuale che salvi per lo scaffold del test si moltiplica.}