J'utilise une variante de richq de réponse. Dans le premier niveau, CMakeLists.txt
,- je ajouter une cible personnalisée, build_and_test
, pour la construction et l'exécution de tous les tests:
find_package(GTest)
if (GTEST_FOUND)
enable_testing()
add_custom_target(build_and_test ${CMAKE_CTEST_COMMAND} -V)
add_subdirectory(test)
endif()
Dans les différentes sous-projet CMakeLists.txt
fichiers en vertu de l' test/
,- je ajouter chaque test exécutables comme une dépendance de l' build_and_test
:
include_directories(${CMAKE_SOURCE_DIR}/src/proj1)
include_directories(${GTEST_INCLUDE_DIRS})
add_executable(proj1_test proj1_test.cpp)
target_link_libraries(proj1_test ${GTEST_BOTH_LIBRARIES} pthread)
add_test(proj1_test proj1_test)
add_dependencies(build_and_test proj1_test)
Avec cette approche, j'ai juste besoin d' make build_and_test
au lieu de make test
(ou make all test
), et il a l'avantage de seul bâtiment le code de test (et ses dépendances). C'est une honte je ne peux pas utiliser le nom de la cible test
. Dans mon cas, c'est pas si mal parce que j'ai un script de niveau supérieur qui n'hors de l'arbre de debug et release (et cross-compilé), construit en appelant cmake
puis make
, et il traduit test
en build_and_test
.
De toute évidence, la GTest choses n'est pas nécessaire. Je viens de passer à utiliser/comme Google Test, et je voulais partager un exemple complet de l'utiliser avec CMake/CTest. À mon humble avis, cette approche a aussi l'avantage de me permettre d'utiliser ctest -V
, ce qui montre le Google Test de sortie, tandis que l'exécution des tests:
1: Running main() from gtest_main.cc
1: [==========] Running 1 test from 1 test case.
1: [----------] Global test environment set-up.
1: [----------] 1 test from proj1
1: [ RUN ] proj1.dummy
1: [ OK ] proj1.dummy (0 ms)
1: [----------] 1 test from proj1 (1 ms total)
1:
1: [----------] Global test environment tear-down
1: [==========] 1 test from 1 test case ran. (1 ms total)
1: [ PASSED ] 1 test.
1/2 Test #1: proj1_test ....................... Passed 0.03 sec