Eu uso uma variante da resposta de richq. No nível superior CMakeLists.txt
, adiciono um destino personalizado,, build_and_test
para criar e executar todos os testes:
find_package(GTest)
if (GTEST_FOUND)
enable_testing()
add_custom_target(build_and_test ${CMAKE_CTEST_COMMAND} -V)
add_subdirectory(test)
endif()
Nos vários CMakeLists.txt
arquivos de subprojeto em test/
, adiciono cada executável de teste como uma dependência 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)
Com essa abordagem, eu só preciso em make build_and_test
vez de make test
(ou make all test
), e tem a vantagem de apenas construir o código de teste (e suas dependências). É uma pena que não posso usar o nome do alvo test
. No meu caso, não é tão ruim porque tenho um script de nível superior que faz a depuração fora da árvore e libera (e compila compilações cruzadas) chamando cmake
e então make
, e isso se traduz test
em build_and_test
.
Obviamente, o material GTest não é necessário. Acontece que eu uso / gosto do Google Test e queria compartilhar um exemplo completo de como usá-lo com o CMake / CTest. IMHO, essa abordagem também tem o benefício de me permitir usar ctest -V
, que mostra a saída do Google Test enquanto os testes são executados:
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