Ich verwende eine Variante von richqs Antwort. In der obersten Ebene CMakeLists.txt
füge ich ein benutzerdefiniertes Ziel hinzu, build_and_test
für die Erstellung und Durchführung aller Tests:
find_package(GTest)
if (GTEST_FOUND)
enable_testing()
add_custom_target(build_and_test ${CMAKE_CTEST_COMMAND} -V)
add_subdirectory(test)
endif()
In den verschiedenen Teilprojekten CMakeLists.txt
Dateien unter test/
füge ich jede ausführbare Testdatei als eine Abhängigkeit von 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)
Bei diesem Ansatz muss ich nur make build_and_test
anstelle von make test
(oder make all test
), und es hat den Vorteil, dass nur Testcode (und dessen Abhängigkeiten) erstellt wird. Es ist eine Schande, dass ich den Zielnamen nicht verwenden kann test
. In meinem Fall ist es nicht so schlimm, weil ich ein Top-Level-Skript habe, das Debug- und Release-Builds (und Cross-Compile-Builds) außerhalb des Baums durch den Aufruf von cmake
und dann make
und wird übersetzt mit test
in build_and_test
.
Die GTest-Sachen sind natürlich nicht erforderlich. Ich benutze/mag Google Test einfach und wollte ein komplettes Beispiel für die Verwendung mit CMake/CTest teilen. IMHO hat dieser Ansatz auch den Vorteil, dass ich ctest -V
die die Ausgabe von Google Test anzeigt, während die Tests laufen:
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