Abbiamo un codice legacy con test unitari (wohooo: D [è quindi ancora legacy?: D]).
Il codice di produzione è un file exe, un altro è una DLL ma con un solo punto di accesso singolo esportato (per alcune interfacce plugin).
Poi ci sono progetti di test unitari separati che devono testare l'exe e la DLL del plugin. L'approccio attuale è molto semplice: includere i sorgenti per l'eseguibile nel progetto di test e testare il codice. Stessa cosa per il file dll.
Questo ha enormi svantaggi: il codice deve essere compilato più volte. La modifica di un file nel exe attiva anche una build per il test. Presumo che il modo in cui è stato fatto era perché eravamo tutti giovani e senza tracce.
AFAIK non esiste un modo corretto di esercitare il codice eseguibile (oltre a chiamare l'eseguibile e osservarne gli effetti) e non è stato possibile testare la DLL solo tramite le funzioni esportate. Non volevamo spammare il codice DLL e l'exe con un sacco di __declspecs per esportare e importare i dati solo per il test. ( Please : questa discussione non dovrebbe riguardare il fatto che dovremmo testare solo l'interfaccia pubblica delle DLL, questo argomento è più complicato).
Ora mi sto rendendo creativo con questo perché il tempo di compilazione è fondamentale per noi e non vogliamo creare una configurazione separata per il file exe e dll che produce una libreria statica poichè questa sarà ancora un overhead di compilazione.
Un approccio che ho fatto è che il progetto di test abbia una fase di pre-build che faccia qualche trucco sporco: raccoglie tutti i file obj esistenti e li collega in una lib di improvvisazione statica che viene consumata dal progetto di test . Funziona molto bene ma presenta ancora alcuni inconvenienti: il passo di pre-build è sempre eseguito, quindi anche se nessun file obj è stato modificato, il collegamento dei file obj deve essere eseguito ogni volta che costruisco il progetto di test - > fastidioso.
Ora ricordo che mi sono divertito ad aggiungere i file obj intermedi direttamente al mio progetto di test, ma ho abbandonato questo approccio.
Aggiungere i file obj ha un vantaggio: Velocità, aggiungo i file obj di cui ho bisogno dal progetto, se non collaudo tutto non ho bisogno di collegare tutti i file obj. Ma questo ha un grosso svantaggio: devo includere manualmente tutti i file obj richiesti. Se l'exe ottiene un altro file .cpp che risulta in un oggetto, potrebbe interrompere la compilazione del codice di test (quando qualcuno ha bisogno di questo nuovo file obj).
Gradirei davvero un diverso punto di vista su questo argomento.
In realtà mi piace molto la generazione di lib di statica improvvisata, ma devo controllare se posso usare qualche funzione di msbuild per rilevare i file modificati per evitare di creare questo file ogni volta.