Pregunta

Estoy intentando CTest en CMake con el fin de ejecutar automáticamente algunos de mis pruebas con destino make test. El problema es CMake no "entiende" que la prueba de que estoy dispuesto a ejecutar tiene que ser construido, ya que es parte del proyecto.

Así que estoy buscando una manera de especificar explícitamente esta dependencia.

¿Fue útil?

Solución

Es podría decirse a href="https://gitlab.kitware.com/cmake/cmake/issues/8774" fallo rel="noreferrer"> (anteriormente seguido aquí ) que esto no funciona fuera de la caja . Una solución consiste en hacer lo siguiente:

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

A continuación, puede ejecutar make check y va a compilar y ejecutar la prueba. Si tiene varias pruebas, entonces se tendría que utilizar DEPENDS exe1 exe2 exe3 ... en la línea anterior.

Otros consejos

En realidad, hay una manera de utilizar make test. Es necesario definir la estructura del ejecutable de prueba como una de las pruebas y luego agregar dependencias entre las pruebas. Es decir:

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)

Yo uso una variante de la respuesta de richq. En el CMakeLists.txt de nivel superior, añado un objetivo de encargo, build_and_test, para crear y ejecutar todas las pruebas:

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

En los diversos archivos CMakeLists.txt sub-proyectos en el marco test/, agrego cada ejecutable de prueba como una dependencia del 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)

Con este enfoque, sólo tengo que make build_and_test en lugar de make test (o make all test), y tiene la ventaja de código de prueba único edificio (y sus dependencias). Es una lástima que no pueda utilizar el nombre de destino test. En mi caso, no es tan malo porque tengo una secuencia de comandos de nivel superior que lo hace fuera del árbol de depuración y liberación (y-cruz compilada) construye llamando cmake y luego make, y se traduce test en build_and_test.

Obviamente, no es necesaria la materia GTEST. Lo que pasa es usar / Google como prueba, y quería compartir un ejemplo completo de usarlo con CMake / CTest. En mi humilde opinión, este enfoque también tiene la ventaja de permitir que utilice ctest -V, que muestra la salida de prueba Google, mientras que las pruebas se ejecutan:

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 usted está tratando de emular make check, puede encontrar útil este wiki entrada:

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

acabo de comprobar que se cumple lo que con éxito (CMake 2.8.10).

Guardar el dolor de cabeza:

make all test

Funciona fuera de la caja para mí y va a construir dependencias antes de ejecutar la prueba. Teniendo en cuenta lo sencillo que es, casi hace la funcionalidad nativa make test conveniente, ya que le da la opción de ejecutar las últimas pruebas de compilación, incluso si el código está roto.

Esto es lo que han negociado y han estado utilizando:

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 está usando CMake> = 3.7, entonces el método recomendado es utilizar accesorios :

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)

Todo lo anterior respuestas son perfectos. Pero en realidad CMake use CTest como sus herramientas de prueba, por lo que el método estándar (creo que es) para hacer la misión es:

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

A continuación, ejecute cmake y make para construir los objetivos. Después de eso, puede ejecutar make test , o simplemente ejecutar

ctest

obtendrá el resultado. Esto se probó bajo CMake 2.8.

Verificar detalles en: http://cmake.org/Wiki/CMake/Testing_With_CTest#Simple_Testing

Todas las respuestas son buenas, pero implican una violación de la tradición para ejecutar una prueba de make test comando. He hecho este truco:

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

Esto significa que la prueba consiste en la construcción (opcionalmente) y funcionando de objetivo ejecutable.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top