Question

我们的C ++项目在Boost / Test中实现了相对较多的测试套件。所有测试都保留在主项目的树之外，每个测试套件都位于单独的.cpp文件中。因此，我们当前用于测试的CMakeLists.txt如下所示：

cmake_minimum_required(VERSION 2.6)

project(TEST_PROJECT)
find_package(Boost COMPONENTS unit_test_framework REQUIRED)

set(SPEC_SOURCES
    main.cpp
    spec_foo.cpp
    spec_bar.cpp
    ...
)

set(MAIN_PATH some/path/to/our/main/tree)    
set(MAIN_SOURCES
    ${MAIN_PATH}/foo.cpp
    ${MAIN_PATH}/bar.cpp
    ...
)

add_executable (test_project
    ${SPEC_SOURCES}
    ${MAIN_SOURCES}
)

target_link_libraries(test_project
    ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY}
)

add_test(test_project test_project)

enable_testing()

它运行正常，但问题是SPEC_SOURCES和MAIN_SOURCES是相当长的列表，有人偶尔会破坏主树或规范源中的任何一个文件中的某些内容。反过来，这使得无法构建目标可执行文件并测试其余的可执行文件。一个人必须手动找出被破坏的内容，进入CMakeLists.txt并注释掉无法编译的部分。

所以，问题：有没有办法忽略在CMake中自动构建的测试，编译，链接和运行其余的测试（理想情况下，将那些失败的测试标记为“未能构建” “）？

远程相关的问题 Best practice using boost test and tests that should not compile建议在CMake中使用try_compile命令。然而，在它的裸露形式中，它只是执行新的临时生成的CMakeList（它将像原始的一样失败）并且没有任何钩子来移除不可编译的单元。

Answer 1

我认为您的测试方法存在一些问题。

必须手动找出损坏的内容，进入CMakeLists.txt并注释掉无法编译的部分。

如果您通过单元测试获得良好的覆盖率，您应该能够快速识别和定位问题。持续集成（例如Jenkins，Buildbot，Travis（GitHub））可能非常有用。即使有些开发人员在提交之前没有这样做，他们也会运行你的测试。

另外，您假设必须从构建中删除非编译类（及其测试）。但是传递依赖性呢，其中非编译类会破坏其他类的编译或导致链接错误。打破构建的测试怎么样？所有这些都发生在开发过程中。

我建议你将你的构建分成许多库，每个库都有自己的测试运行器。把所有的东西放在一起（凝聚力）。尝试最小化编译中的依赖项（依赖注入，接口，...）。这将允许通过编译库和测试运行器来保持开发，即使某些库不编译（一段时间）。

Answer 2

我猜你可以为每个规范源创建一个测试可执行文件（使用foreach() loop）然后执行以下操作：

make spec_foo &&  ./spec_foo

这只会尝试构建与您要运行的测试匹配的二进制文件

但如果您的构建经常失败，则可能表明您的生产代码中有一些糟糕的设计......

CMake + Boost测试：忽略无法构建的测试

2 个答案: