CMake & CTest: make test nie tworzy testów

Próbuję CTest w CMake, aby automatycznie uruchamiać niektóre z moich testów przy użyciu make testcelu. Problem polega na tym, że CMake nie „rozumie”, że test, który chcę uruchomić, musi zostać zbudowany, ponieważ jest częścią projektu.

Dlatego szukam sposobu na jawne określenie tej zależności.

Jest to prawdopodobnie jest błąd w CMake (śledzone wcześniej tutaj ), że to nie działa po wyjęciu z pudełka. Aby obejść ten problem, wykonaj następujące czynności:

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

Następnie możesz uruchomić, make checka on skompiluje i uruchomi test. Jeśli masz kilka testów, musisz użyć DEPENDS exe1 exe2 exe3 ...w powyższej linii.

Właściwie jest sposób na użycie make test. Musisz zdefiniować kompilację pliku wykonywalnego testu jako jeden z testów, a następnie dodać zależności między testami. To jest:

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)

Używam wariantu odpowiedzi Richqa. Na najwyższym poziomie CMakeLists.txtdodaję cel niestandardowy build_and_testdo tworzenia i uruchamiania wszystkich testów:

find_package(GTest)
if (GTEST_FOUND)
    enable_testing()
    add_custom_target(build_and_test ${CMAKE_CTEST_COMMAND} -V)
    add_subdirectory(test)
endif()

W różnych CMakeLists.txtplikach podprojektów poniżej test/dodaję każdy plik wykonywalny testu jako zależność 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)

Przy takim podejściu po prostu muszę make build_and_testzamiast make test(lub make all test), a to ma tę zaletę, że buduje tylko kod testowy (i jego zależności). Szkoda, że ​​nie mogę użyć nazwy docelowej test. W moim przypadku nie jest tak źle, ponieważ mam skrypt najwyższego poziomu, który wykonuje debugowanie poza drzewem i zwalnia (i kompiluje krzyżowo), wywołując, cmakea następnie make, i przekłada się to testna build_and_test.

Oczywiście rzeczy GTest nie są wymagane. Po prostu używam / lubię Google Test i chciałem podzielić się pełnym przykładem użycia go z CMake / CTest. IMHO, to podejście ma również tę zaletę, że pozwala mi używać ctest -V, które pokazuje wyniki testu Google podczas wykonywania testów:

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

Jeśli próbujesz emulować make check, ten wpis wiki może okazać się przydatny:

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

Właśnie sprawdziłem, że robi to, co mówi, z sukcesem (CMake 2.8.10).

Oszczędź sobie bólu głowy:

make all test

U mnie działa po wyjęciu z pudełka i przed uruchomieniem testu zbuduje zależności. Biorąc pod uwagę, jak proste jest to, prawie sprawia, że ​​natywna make testfunkcjonalność jest wygodna, ponieważ daje możliwość uruchomienia ostatnich testów kompilacji, nawet jeśli twój kod jest uszkodzony.

Jeśli używasz CMake> = 3.7, zalecanym podejściem jest użycie urządzeń :

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

Robi to w następujący sposób:

• Dodaje testwykonywalny cel zbudowany ztest.cpp
• Dodaje test_build„test”, który uruchamia Cmake, aby zbudować celtest
• Oznacza test_buildtest jako zadanie konfiguracyjne urządzeniatest_fixture
• Dodaj testtest, który po prostu uruchamia testplik wykonywalny
• Oznacza testtest jako wymagający zamocowania test_fixture.

Tak więc za każdym razem, gdy test testma być uruchomiony, najpierw uruchamia test test_build, który buduje niezbędny plik wykonywalny.

Oto, co wymyśliłem i używałem:

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

Odpowiedź Derricka, uproszczona i skomentowana:

# It is impossible to make target "test" depend on "all":
# https://gitlab.kitware.com/cmake/cmake/-/issues/8774
# Set a magic variable in a magic file that tells ctest
# to invoke the generator once before running the tests:
file(WRITE "${CMAKE_BINARY_DIR}/CTestCustom.cmake"
    "set(CTEST_CUSTOM_PRE_TEST ${CMAKE_MAKE_PROGRAM})\n"
)

Nie jest to całkowicie poprawne, ponieważ nie rozwiązuje problemu współbieżności uruchamiania ninja all test, na wypadek gdyby ktoś to zrobił. Wręcz przeciwnie, ponieważ teraz masz dwa procesy ninja.

(Ftr, ja również wspólne rozwiązanie to tutaj .)

Wszystkie powyższe odpowiedzi są doskonałe. Ale tak naprawdę CMake używa CTest jako swoich narzędzi testowych, więc standardowa metoda (myślę, że tak) do wykonania misji to:

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

Następnie uruchom cmake i zrobić zbudować cele. Następnie możesz uruchomić make test lub po prostu uruchomić

ctest

otrzymasz wynik. Jest to testowane pod CMake 2.8.

Sprawdź szczegóły na: http://cmake.org/Wiki/CMake/Testing_With_CTest#Simple_Testing

Wszystkie odpowiedzi są dobre, ale sugerują naruszenie tradycji przeprowadzania testu na polecenie make test. Zrobiłem tę sztuczkę:

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

Oznacza to, że test składa się z kompilacji (opcjonalnie) i uruchomienia wykonywalnego celu.