2013-02-09 8 views
12

Sto lavorando su un progetto procedurale C/C++. L'interfaccia pubblica è composta da 4 funzioni, ciascuna con compiti abbastanza complessi. Ci sono funzioni di supporto dichiarate nello stesso file cpp, in uno spazio dei nomi senza nome. Il framework di test utilizzato è GTest.Unit Testing C++ Code in uno spazio dei nomi senza nome

Tuttavia, alcune di queste funzioni di supporto stanno diventando abbastanza complesse da richiedere il test dell'unità. Normalmente, vorrei refactoring questi helper nelle proprie unità testabili, ma i requisiti del progetto indicano che tutto deve essere in uno cpp, e solo le funzioni specificate possono essere visibili pubblicamente.

Esiste un modo per testare le funzioni dell'helper riducendo al minimo l'accoppiamento e seguendo i requisiti del progetto il più vicino possibile?

Una possibile soluzione era utilizzare una macro per trasformare lo spazio dei nomi in un nome per il test e senza nome per la produzione. Tuttavia, mi è sembrato un po 'più confuso di quanto vorrei.

+0

Possibile duplicato di [Come posso testare una classe che ha metodi privati, campi o classi interne?] (Https://stackoverflow.com/questions/34571/how-do-i-test-a-class-that -has-private-methods-fields-or-inner-classes) – Raedwald

risposta

12

Entrambe le definizioni e dichiarazioni in un anonimo namespace sono visibili solo all'interno della stessa unità di traduzione.

Esistono due approcci che è possibile eseguire per il test di unità di queste funzioni private.

È possibile l'intero file .cpp testato nel file _test.cpp. (#include ing .cpp file non è un buon modo per riutilizzare il codice - non si dovrebbe fare questo nel codice di produzione!)

Forse un approccio migliore è quello di spostare il codice privato in una foo::internalnamespace, dove foo è il namespace vostro progetto normalmente usa e inserisce le dichiarazioni private in un file -internal.h. I tuoi file di produzione .cpp e i tuoi test sono autorizzati a includere questa intestazione interna, ma i tuoi clienti non lo sono. In questo modo, puoi testare completamente la tua implementazione interna senza farla trapelare ai tuoi clienti.

+0

Grazie, questo aiuta molto. –

+6

Per il secondo metodo, lo spostamento di oggetti nello spazio dei nomi nominato significa che manterrà un'identità di runtime di riferimento, e sembra svuotare il motivo dell'utilizzo di namespace anonimo - vietando completamente qualsiasi accesso dall'unità di compilazione ... Inoltre sembra consentire il nome accidentale ... – Eonil

+0

Davvero come la tua prima idea. Mi chiedo se qualcuno mi sparerà per averlo fatto. – zehelvion

Problemi correlati