CMake & CTest : faire le test de ne pas construire des tests

Il est sans doute un bug dans CMake (auparavant suivre ici) que cela ne fonctionne pas hors de la boîte. Une solution de contournement consiste à effectuer les opérations suivantes:

add_test(TestName ExeName)
add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND}
                  DEPENDS ExeName)

Ensuite, vous pouvez exécuter make check et compiler et exécuter le test. Si vous avez plusieurs tests, alors que vous auriez à utiliser DEPENDS exe1 exe2 exe3 ... dans la ligne ci-dessus.

J'utilise une variante de richq de réponse. Dans le haut-niveau CMakeLists.txt, j'ai 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 sous test/, j'ajoute chaque test exécutable en tant que dépendance de 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 de 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 et puis make, et il traduit test en build_and_test.

Évidemment, 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

Vous épargner les maux de tête:

make all test

Fonctionne hors de la boîte pour moi et les dépendances de construction avant d'exécuter le test. Compte tenu de la façon simple, c'est que ça rend le natif make test fonctionnalité très pratique car il vous donne la possibilité de l'exécution de la dernière compilation de tests, même si votre code est cassé.

Si vous êtes en utilisant CMake >= 3.7, puis l'approche recommandée consiste à utiliser luminaires:

add_executable(test test.cpp)
add_test(test_build
  "${CMAKE_COMMAND}"
  --build "${CMAKE_BINARY_DIR}"
  --config $<CONFIG>
  --target test
)
add_test(test test)
set_tests_properties(test       PROPERTIES FIXTURES_REQUIRED test_fixture)
set_tests_properties(test_build PROPERTIES FIXTURES_SETUP    test_fixture)

Toutes les réponses sont bonnes, mais elles impliquent une violation de la tradition pour l'exécution d'un test par la commande make test. J'ai fait ce truc:

add_test(NAME <mytest>
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMAND sh -c "make <mytarget>; $<TARGET_FILE:<mytarget>>")

Cela signifie que le test se compose de la construction (en option) et l'exécution de l'exécutable cible.