Question

Je suis en train CTest à CMake afin d'exécuter automatiquement certaines de mes tests à l'aide de la cible make test. Le problème est CMake ne pas « comprendre » que le test je suis prêt à courir doit être construit car il fait partie du projet.

Je suis à la recherche d'un moyen de spécifier explicitement cette dépendance.

Était-ce utile?

La solution

Il est sans doute dans CMake (auparavant suivi ) que cela ne fonctionne pas hors de la boîte . Une solution 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 il compiler et exécuter le test. Si vous avez plusieurs tests, vous devrez alors utiliser DEPENDS exe1 exe2 exe3 ... dans la ligne ci-dessus.

Autres conseils

Il est en fait un moyen d'utiliser make test. Vous devez définir la construction de l'exécutable d'essai comme l'un des tests, puis ajouter des dépendances entre les tests. C'est:

ADD_TEST(ctest_build_test_code
         "${CMAKE_COMMAND}" --build ${CMAKE_BINARY_DIR} --target test_code)
ADD_TEST(ctest_run_test_code test_code)
SET_TESTS_PROPERTIES(ctest_run_test_code
                     PROPERTIES DEPENDS ctest_build_test_code)

J'utilise une variante de la réponse de richq. Dans le CMakeLists.txt haut niveau, ajouter une cible personnalisée, build_and_test, pour la construction et l'exécution 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érents fichiers CMakeLists.txt sous-projet test/, ajouter chaque exécutable de test 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 make build_and_test au lieu de make test (ou make all test), et il a l'avantage de ne code de test de construction (et ses dépendances). Il est dommage que je ne peux pas utiliser le nom de la cible test. Dans mon cas, ce n'est pas si mal parce que j'ai un script de haut niveau qui fait hors arbre débogage et la libération (et compilé de façon croisée) construit en appelant cmake puis make, et il se traduit test en build_and_test.

De toute évidence, les choses gtest n'est pas nécessaire. Je viens d'arriver à 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, qui montre la sortie de test Google pendant 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

Si vous essayez d'imiter make check, vous pouvez trouver cette entrée wiki utile:

http://www.cmake.org/Wiki/CMakeEmulateMakeCheck

Je viens de vérifier ce qui est fait ce qu'il dit avec succès (CMake 2.8.10).

Epargnez-vous le mal de tête:

make all test

Travaux de la boîte pour moi et va construire des dépendances avant d'exécuter le test. Compte tenu de la façon dont cela est simple, il fait presque la fonctionnalité make test native pratique car il vous donne la possibilité d'exécuter les derniers tests de compilation même si votre code est cassé.

Voici ce que je martelés et ai utilisé:

set(${PROJECT_NAME}_TESTS a b c)

enable_testing()
add_custom_target(all_tests)
foreach(test ${${PROJECT_NAME}_TESTS})
        add_executable(${test} EXCLUDE_FROM_ALL ${test}.cc)
        add_test(NAME ${test} COMMAND $<TARGET_FILE:${test}>)
        add_dependencies(all_tests ${test})
endforeach(test)

build_command(CTEST_CUSTOM_PRE_TEST TARGET all_tests)
string(CONFIGURE \"@CTEST_CUSTOM_PRE_TEST@\" CTEST_CUSTOM_PRE_TEST_QUOTED ESCAPE_QUOTES)
file(WRITE "${CMAKE_BINARY_DIR}/CTestCustom.cmake" "set(CTEST_CUSTOM_PRE_TEST ${CTEST_CUSTOM_PRE_TEST_QUOTED})" "\n")

YMMV

Si vous utilisez CMake> = 3.7, l'approche recommandée est d'utiliser accessoires:

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 ci-dessus sont parfaits. Mais en fait CMake utiliser CTest comme ses outils de test, la méthode standard (je pense qu'il est) de faire la mission est:

enable_testing ()
add_test (TestName TestCommand)
add_test (TestName2 AnotherTestCommand)

Ensuite, exécutez cmake et faire pour construire les cibles. Après cela, vous pouvez exécuter make test , ou tout simplement lancer

ctest

vous obtiendrez le résultat. Ceci est testé sous CMake 2.8.

Vérifiez les détails à: http://cmake.org/Wiki/CMake/Testing_With_CTest#Simple_Testing

Toutes les réponses sont bonnes, mais elles impliquent une violation de la tradition d'exécuter un test par commande make test. Je l'ai fait cette astuce:

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

Cela signifie que le test consiste à construire (éventuellement) et l'exécution de la cible exécutable.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top