CTest是CMake内置测试驱动器，启用需调用enable_testing()并用add_test()注册独立可执行文件；集成gtest需链接GTest::gtest_main，Boost.Test须定义BOOST_TEST_DYN_LINK。
CTest 是 CMake 内置的测试驱动器，不是可选插件
只要你调用 enable_testing()，CMake 就会启用 CTest 支持——它不依赖任何第三方测试框架，也不需要额外安装。很多开发者误以为必须先集成 gtest 或 Boost.Test 才能“有测试”，其实 CTest 本身就能跑任意可执行程序，并捕获其退出码作为通过/失败判断。
常见错误现象：make test 报错 “No tests defined” 或直接静默退出，往往是因为漏掉了 enable_testing()，或没用 add_test() 注册测试目标。
-
enable_testing()必须出现在根CMakeLists.txt中，且要在所有add_test()之前 - 每个测试必须是独立可执行文件（哪怕只有一行
return 0;），CTest 不接受库或脚本直接注册 - 测试名不能含空格或特殊字符，否则
ctest -R "my test"会匹配失败
用 add_test() 注册测试时，路径和工作目录容易出错
add_test() 的第一个参数是测试名，第二个是可执行文件路径——这个路径是构建时的相对路径（从构建目录算起），不是源码目录下的路径。比如你写了 add_test(NAME my_test COMMAND test_example)，那 test_example 必须已由 add_executable() 构建出来，且位于 CMAKE_BINARY_DIR 或其子目录下。
容易踩的坑：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 没设置
WORKING_DIRECTORY，导致测试里读取的data/input.txt找不到——默认工作目录是构建根目录，不是测试可执行文件所在目录 - 误把源码路径当构建路径，写成
COMMAND ${CMAKE_SOURCE_DIR}/tests/test_example，结果构建时找不到该文件（因为还没编译） - 在子目录
CMakeLists.txt中调用add_test()，但没确保父级已调用enable_testing()
集成 gtest 时，链接 GTest::gtest_main 很关键
如果你用 find_package(GTest REQUIRED)，就别自己写 main() 函数。直接链接 GTest::gtest_main，它会提供标准入口并自动运行所有 TEST 宏定义的用例。自己实现 main() 容易漏掉 testing::InitGoogleTest() 或 RUN_ALL_TESTS()，导致测试根本没执行。
实操建议：
- 测试可执行文件必须同时链接
GTest::gtest和GTest::gtest_main，只链前者会报 undefined reference 到main - 不要对测试目标重复设置
set(CMAKE_CXX_STANDARD ...)，继承父级即可；但需确保GTest::gtest编译标准与你的代码一致（比如都用 C++17） - 若用
FetchContent拉取 gtest，务必在project()之后、add_executable()之前调用FetchContent_MakeAvailable()，否则 target_link_libraries 会找不到目标
Boost.Test 需要 BOOST_TEST_DYN_LINK 且不能和静态链接混用
Boost.Test 默认以动态方式链接其运行时（libboost_unit_test_framework.so/.dll），所以必须加 target_compile_definitions(cpp_test PRIVATE BOOST_TEST_DYN_LINK)。如果漏了这行，BOOST_AUTO_TEST_CASE 宏会展开失败，编译报 undefined reference to 'boost::unit_test::framework::master_test_suite()'。
更隐蔽的问题：
- 若项目其他部分用了
Boost::system等静态库，而 Boost.Test 动态链接，可能引发符号冲突或 ABI 不兼容（尤其在 macOS 上） -
find_package(Boost 1.54 REQUIRED COMPONENTS unit_test_framework)中的版本号不能低于实际安装版本，否则find_package会静默失败，后续target_link_libraries报错找不到Boost::unit_test_framework -
#define BOOST_TEST_MODULE必须在#include <boost></boost>之前，顺序反了会导致宏未生效
最常被忽略的一点：CTest 的 ctest --output-on-failure 和 ctest -j 并非总能如实反映测试失败原因——尤其是当测试进程因信号（如 SIGSEGV）崩溃时，输出可能被截断。真要调试，得直接运行测试可执行文件，或加 valgrind / AddressSanitizer 启动。
