¿Cuál es su estructura de proyecto/estructura de proyecto favorita/recomendada para Pruebas unitarias usando Boost?

Question

Hasta el momento, no he usado pruebas unitarias, y tengo la intención de adoptar este procedimiento. Estoy impresionado por TDD y ciertamente quiero probarlo, estoy casi seguro de que es el camino a seguir.

Boost parece una buena opción, principalmente porque se mantiene. Dicho esto, ¿cómo debería implementar una estructura de archivos y proyectos funcional y elegante? Estoy usando VS 2005 en Win XP. He estado buscando en Google sobre esto y estaba más confundido que iluminado.

Answer 1

Nuestra estructura de las pruebas basadas Boost se ve así:

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 
     ... 

Esta estructura fue elegido para un proyecto de legado, donde tuvimos que decidir sobre una base de caso por caso en lo que pone a prueba a añadir y cómo proyectos de prueba grupales para módulos existentes de código fuente.

A tener en cuenta: Código de Prueba

• Unidad siempre se compila por separado del código de producción.
• Los proyectos de producción no hacen referencia al código de prueba de la unidad.
• Los proyectos de pruebas unitarias incluyen directamente los archivos de origen o solo las bibliotecas de referencia, dependiendo de lo que tenga sentido dado el uso de un determinado archivo de código.
• La ejecución de las pruebas unitarias se realiza a través de un paso posterior a la construcción en cada ut _ *. Vcproj
• Todas nuestras construcciones de producción también ejecutan automáticamente las pruebas unitarias. (En nuestras secuencias de comandos de compilación)

En nuestro mundo real (C++) tiene que hacer concesiones por cierto. problemas heredados, conveniencia del desarrollador, tiempos de compilación, etc. Creo que nuestra estructura de proyecto es una buena solución de compromiso. :-)

Answer 2

Exploré mi código central en .libs o .dlls y luego dejo que mis proyectos de prueba de Boost dependan de estos proyectos lib/dll. Por lo que podría terminar con:

ProjectRoot 
    Lib1Source 
    Lib1Tests 
    Lib2Source 
    Lib2Tests 

La alternativa es almacenar su fuente en una carpeta separada y añadir los archivos a la vez su principal proyecto de aplicaciones y el proyecto de prueba de unidad, pero me parece un poco desordenado. YMMV.