CMake目前已经很好地和gtest进行了集成。
只要通过 include(GoogleTest)，我们就可以调用gtest_discover_tests或者gtest_add_tests来自动为我们添加测试用例到CMake中了，
一旦测试用例添加到CMake中，那么我们就可以通过CTest执行相应的单元测试用例，实现单元测试的自动化。
今天我们来分析一下gtest_discover_tests的逻辑，譬如下面代码：
include(GoogleTest)
gtest_discover_tests(${GTEST_PROJECT_NAME}
TEST_LIST gtest)
set_property(DIRECTORY APPEND PROPERTY
TEST_INCLUDE_FILES
${CMAKE_CURRENT_LIST_DIR}/SetTestsProperty.cmake)
这里，我们通过gtest_discover_test对某个测试用例可执行程序Target进行查询，查询得到可执行程序的所有测试用例的列表。然后利用add_test会自动添加到CMake的测试用例中，所以后面我们可以用CTest执行测试用例了。
这么看，似乎和我们手工添加测试用例没什么分别的。
但是，其实不然，仔细想一下，gtest_discover_test依赖的是测试用例可执行程序Target，它需要查询可执行程序，让可执行告诉它测试用例列表，所以，首先，gtest_discover_test这个逻辑应该是在build阶段才能执行的，而且至少是它依赖的测试用例可执行程序已经构建完成了以后才能开始执行的。
没错！所以它是区别于gtest_add_tests指令函数的逻辑的，gtest_add_tests是会扫描源码文件来得到测试用例列表的。它们用了两种不同的方法，虽然说最终结果是一致的，但是我感觉是用gtest_discover_test更加好，毕竟源代码真正编译出来以后到底包含了哪些测试用例这个会更加准确一些，而通过扫描源码文件来分析得到测试用例列表可能会不一定准确。
在构建完成后，gtest_discover_tests指令会生成${GTEST_PROJECT_NAME} [1]_include.cmake文件和${GTEST_PROJECT_NAME} [1]_tests.cmake和，以及CTestsTestfile.cmake文件，
我们打开CTestsTestfile.cmake文件，可以看到两个include，一个是包含了${GTEST_PROJECT_NAME} [1]_include.cmake文件，一个是包含了SetTestsProperty.cmak文件（这个文件是通过set_property中设置 TEST_INCLUDE_FILES属性告诉cmake的），这两个文件干什么呢？
include文件又转头包含了${GTEST_PROJECT_NAME} [1]_tests.cmake文件，该文件通过add_test添加了测试用例，还通过类似下面的命令将测试用例名字列表添加到了gtest变量中。
set( gtest FileLogTest.test1 ConsoleLogTest.test2)
于是，在我们的SetTestsProperty.cmake脚本中，可以通过这个gtest变量来遍历所有发现的测试用例，进行测试用例的相关特性设置，譬如对其设置测试超时时间，设置标签等。
而这些逻辑自然是放在CTest执行测试用例之前来进行的。
总结一下，gtest_discover_test在构建阶段来发现测试用例列表，并将其写入cmake文件，CTest在测试阶段运行build阶段产生的cmake文件，以及通过set_property设置的TEST_INCLUDE_FILES特性中指定的cmake脚本来执行一些自定义的处理。
如果对cmake学习感兴趣，可以点击《一起发现CMake太美》课程的 链接 可以进入视频课程的学习。在这个课程中，用六个CMake实例项目，深入浅出、层层递进，打通项目构建过程的奇经八脉，涵盖编译、链接、测试、源码质检、安装、打包全部环节，助您轻松进入CMake大门，提升软件构建过程的自动化水平。
