当我使用ctest接口cmake(add_test(...)
)并运行make target make test
时,我的几个测试都失败了。当我直接从二进制构建文件夹的命令行运行每个测试时,它们都可以工作。
我可以使用什么来调试它?
答案 0 :(得分:4)
要进行调试,您可以先直接运行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
之类的路径。
答案 1 :(得分:1)
ctest和googletest的问题在于它假定为每个测试用例运行一个命令,而您可能会在单个测试可执行文件中运行许多不同的测试用例。因此,当您将add_test
与Google Test可执行文件一起使用时,CTest
会报告单个失败,无论实际失败的测试用例数是1还是1000。
既然你说运行你的测试用例让它们通过,我首先怀疑你的测试是以某种方式耦合的。您可以通过使用--gtest_shuffle
随机化测试执行顺序来快速检查,并查看是否出现相同的故障。
我认为调试失败测试用例的最佳方法是不使用CTest
,而只是使用command line options运行测试可执行文件来过滤运行的实际测试用例。我将首先运行第一个与整个测试套件运行之前的测试运行一起失败的测试。
调试测试用例的其他有用工具可以是SCOPED_TRACE
,并使用其他信息扩展断言消息。