当我使用 ctest 接口进行 cmake (add_test(...)) 并运行 make 目标 make test 时，我的一些测试失败了。当我直接从二进制构建文件夹的命令行运行每个测试时，它们都可以工作。
我可以用什么来调试这个？
【问题讨论】：
add_test吗？
标签： cmake googletest ctest
要调试，可以先直接运行ctest，而不是make test。
然后您可以将-V 选项添加到ctest 以获得详细输出。
第三个neat trick from a cmake developer 是让 ctest 启动一个 xterm shell。所以添加
add_test(run_xterm xterm)
在最后的 CMakeLists.txt 文件中。然后运行make test，它会打开一个xterm。然后看看你是否可以通过从 xterm 运行它来复制失败的测试。如果确实失败，请检查您的环境（即从 xterm 运行 env > xterm.env，然后从正常会话中再次运行 env > regular.env 并比较输出）。
我发现我的测试是为了查找通过二进制 cmake 输出文件夹的 top 的相对路径传递的外部文件（即您键入 make test 的那个）。但是，当您通过 ctest 运行测试时，当前工作目录是该特定子目录的二进制文件夹，因此测试失败。
换句话说：
成功了
test/mytest
但这没有用
cd test; ./mytest
我必须修复单元测试以使用它所需的配置文件的绝对路径，而不是像 ../../../testvector/foo.txt 这样的路径。
【讨论】：
ctest 和 googletest 的问题在于它假定为每个测试用例运行一个命令，而您可能会在单个测试可执行文件中运行许多不同的测试用例。因此，当您将 add_test 与 Google 测试可执行文件一起使用时，CTest 会报告一次失败，无论失败的测试用例的实际数量是 1 还是 1000。
既然您说孤立地运行测试用例会使它们通过，我的第一个怀疑是您的测试以某种方式耦合。您可以通过使用--gtest_shuffle 随机化测试执行顺序来快速检查这一点，看看您是否遇到相同的失败。
我认为调试失败的测试用例的最佳方法不是使用CTest，而只是使用command line options 运行测试可执行文件以过滤正在运行的实际测试用例。我会首先只运行第一个失败的测试以及在整个测试套件运行之前的测试运行。
调试测试用例的其他有用工具可以是SCOPED_TRACE，并使用附加信息扩展您的断言消息。
【讨论】：