Devo simulare anche i file di intestazione?

3

Quindi, faccio parte di un progetto molto ampio che non ha, ancora, test delle unità (brivido!) e voglio introdurlo.

Ho intenzione di utilizzare Google Test e Google Mock.

Il codice è grande e ingombrante e soffre di "header spaghetti".

Se desidero, per motivi di semplicità, testare solo a.cpp che chiama solo una singola funzione in b.cpp, allora posso usare Google Mock per generare un mock per b.cpp.

Tuttavia, se # includo bh in a.cpp e nella mia suite di test, trovo che bh # include un numero di altre intestazioni, che a sua volta ... alla fine, includo centinaia di intestazioni.

Non ci sarà alcuna ristrutturazione dei file header (in qualunque momento presto, se mai). Devo solo conviverci.

Fino ad ora, il codice è stato creato solo come sistema completo, per un processore ARM, e ora voglio creare a.cpp plus b.cpp più Google test per l'esecuzione su Linux.

Ho grossi problemi in quanto ci sono centinaia di commutatori (!) nel compilatore del sistema e non riesco a vedere quali sono necessari dove, che sono solo ARM, cosa li sostituirà per Linux, ecc.

Inoltre, alcuni di essi contengono #defines che si espandono per funzionare chiamate (soprattutto dal registro di traccia, ma anche per gli altri), e non so dove trovarli per deriderli.

Infine la domanda: come viene gestita normalmente? Dovrei fare una simulazione di b.h, che contiene solo ciò che è necessario a.cpp?

Se è così, devo farlo manualmente o Google Mock può aiutarti in qualche modo?

E, no, il codice non sarà ristrutturato; almeno non immediatamente, per timore di destabilizzarlo.

Non mi piace l'idea di inserire la maggior parte delle intestazioni nel sistema, ma non riesco a trovare un modo semplice per deriderle: - (

    
posta Mawg 09.09.2015 - 14:22
fonte

2 risposte

2

Dato che stai lavorando su un sistema legacy (nessun test unitario), lo troverai piuttosto difficile senza modificare il codice e il refactoring.

L'uso migliore dei mock è con una sorta di iniezione di dipendenza. Iniezione di un oggetto mock, invece della vera classe. E not con dipendenza da iniezioni collegando diversi file oggetto (cosa stai cercando di fare).

Il modo migliore per iniziare è trovare quello che puoi testare, senza usare i mock. Poi, quando hai tempo per il refactoring, regola le classi in qualche modo inietta la dipendenza e poi usa i mock.

    
risposta data 09.09.2015 - 15:40
fonte
2

Il problema che dovrai affrontare è lo stile di test delle unità che hai scelto, in cui ogni cosa al di fuori di un singolo file viene derisa, è in realtà inutile quando si prova un codice non scritto per essere compatibile con esso.

Le tue alternative sono:

  • Confermare esaurientemente questa conclusione e dire alla tua squadra che "ho provato, ma non c'è alcun senso nel test delle unità".
  • riscrivi il codice (che hai detto che non puoi fare).
  • adotta una definizione / stile di test unitario che aggiunge valore dato il codice esistente

Quest'ultimo significherebbe:

  • nessun mocking di nulla tranne l'hardware esterno o le interfacce temporali
  • costruisce test incrementalmente verso l'alto dai componenti standalone di livello più basso ai sistemi integrati di livello superiore.
  • utilizzando i file di costruzione e di intestazione esistenti (perché se un codice non funziona con un determinato flag del compilatore e viene utilizzato il flag del compilatore, il test deve fallire).

In altre parole, per un sistema embedded legacy, non esiste un test unitario nel senso che si ottiene con linguaggi di livello superiore. Semplicemente perché ti stai sempre integrando con il compilatore, se non altro. E quel compilatore è tipicamente un tale disordine di bug, soluzioni temporanee e limiti non documentati che vuoi veramente testare il codice esatto da usare, non un'astrazione.

    
risposta data 22.09.2015 - 17:19
fonte

Leggi altre domande sui tag