cmake add_test () с другим runtime_output_directory [дубликат]

Все ответы хороши, но они подразумевают нарушение традиции для запуска теста командой make test. Я сделал этот трюк:

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

Это означает, что тест состоит из построения (необязательно) и запуска исполняемой цели.

Все вышеприведенные ответы идеальны. Но на самом деле CMake использует CTest в качестве своих инструментов тестирования, поэтому стандартный метод (я думаю, что это) выполняет миссию:

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

Затем запустите cmake и создайте цели. После этого вы можете либо запустить make test, либо просто запустить

ctest

, вы получите результат. Это проверено в CMake 2.8.

Проверьте данные на: http://cmake.org/Wiki/CMake/Testing_With_CTest#Simple_Testing

На самом деле есть способ использовать make test. Вам нужно определить сборку тестового исполняемого файла как один из тестов, а затем добавить зависимости между тестами. То есть:

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)

Сохраните головную боль:

make all test

Работает из коробки для меня и будет создавать зависимости перед запуском теста. Учитывая, насколько это просто, это почти делает функциональность make test удобной, поскольку она дает вам возможность запускать последние компиляционные тесты, даже если ваш код поврежден.

Если вы пытаетесь эмулировать make check, вы можете найти эту запись в вики полезно:

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

Я только что проверил, что это делает то, что он говорит с успехом (CMake 2.8.10).

Я использую вариант ответа richq. На верхнем уровне CMakeLists.txt я добавляю пользовательскую цель build_and_test для создания и запуска всех тестов:

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

В различных файлах подпроектов CMakeLists.txt в разделе test/ , Я добавляю каждый тестовый исполняемый файл как зависимость от 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)

При таком подходе мне просто нужно make build_and_test вместо make test (или make all test), и он имеет преимущество только в создании тестового кода (и его зависимостей). Жаль, я не могу использовать целевое имя test. В моем случае это не так уж плохо, потому что у меня есть сценарий верхнего уровня, который выполняет отладочную и выпускную сборку (и кросс-скомпилированные) сборки, вызывая cmake, а затем make, и он переводит test в build_and_test.

Очевидно, что материал GTest не требуется. Я просто использовал / как Google Test и хотел поделиться полным примером использования его с CMake / CTest. IMHO, этот подход также имеет преимущество, позволяя мне использовать ctest -V, который показывает результат тестирования Google во время тестов:

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