Qual è la struttura del tuo progetto/struttura preferita e la struttura dei file per il test unitario usando Boost?

Question

Finora non ho utilizzato il Test unità e intendo adottare questa procedura. Sono rimasto impressionato da TDD e certamente voglio provarlo - sono quasi sicuro che sia la strada da percorrere.

Boost sembra una buona scelta, soprattutto perché viene mantenuto. Detto questo, come dovrei implementare una struttura di file ed una struttura di progetto funzionante ed elegante? Sto usando VS 2005 in Win XP. Sono stato google su questo ed era più confuso che illuminato.

Answer 1

nostra struttura Testing basato Boost si presenta così:

ProjectRoot/ 
    Library1/ 
    lib1.vcproj 
    lib1.cpp 
    classX.cpp 
    ... 
    Library2/ 
    lib2.vcproj 
    lib2.cpp 
    toolB.cpp 
    classY.cpp 
    ... 
    MainExecutable/ 
    main.cpp 
    toolA.cpp 
    toolB.cpp 
    classZ.cpp 
    ... 
    Tests/ 
    unittests.sln 
    ut_lib1/ 
     ut_lib1.vcproj (referencing the lib1 project) 
     ut_lib1.cpp (with BOOST_AUTO_TEST_CASE) - testing public interface of lib1 
     ut_classX.cpp - testing of a class or other entity might be split 
         into a separate test file for size reasons or if the entity 
         is not part of the public interface of the library 
     ... 
    ut_lib2/ 
     ut_lib2.vcproj (referencing the lib2 project) 
     ut_lib2.cpp (with BOOST_AUTO_TEST_CASE) - testing public interface of lib2 
     ... 
    ut_toolA/ 
     ut_toolA.vcproj (referencing the toolA.cpp file) 
     ut_toolA.cpp - testing functions of toolA 
    ut_toolB/ 
     ut_toolB.vcproj (referencing the toolB.cpp file) 
     ut_toolB.cpp - testing functions of toolB 
    ut_main/ 
     ut_main.vcproj (referencing all required cpp files from the main project) 
     ut_classZ.cpp - testing classZ 
     ... 

Tale struttura è stato scelto per un progetto legacy, dove abbiamo dovuto decidere, caso per caso, su quali esami per aggiungere e come progetti di test di gruppo per moduli esistenti di codice sorgente.

Cose da notare:

• Unità codice di test è sempre compilato separatamente dal codice di produzione.
• I progetti di produzione non fanno riferimento al codice di test dell'unità.
• I progetti di test delle unità includono direttamente i file di origine o solo le librerie di riferimento, a seconda di ciò che è logico dato l'uso di un determinato file di codice.
• L'esecuzione dei test dell'unità avviene tramite un passaggio post-produzione in ogni ut _ *. Vcproj
• Tutte le nostre build di produzione eseguono automaticamente anche i test unitari. (Nei nostri script di compilazione.)

Nel nostro mondo reale (C++) devi fare dei compromessi. problemi legacy, convenienza degli sviluppatori, tempi di compilazione, ecc. Penso che la struttura del nostro progetto sia un buon compromesso. :-)

Answer 2

Ho rovesciato il mio codice core in .libs o .dlls e quindi i miei progetti di test Boost dipendono da questi progetti lib/dll. Quindi potrei finire con:

ProjectRoot 
    Lib1Source 
    Lib1Tests 
    Lib2Source 
    Lib2Tests 

L'alternativa è quella di memorizzare la vostra fonte in una cartella separata e aggiungere i file sia per il vostro progetto app principale e il progetto di test unità, ma trovo questo un po 'disordinato. YMMV.