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