使用 gtest 框架在运行时以编程方式确定的重复测试子集

Repeat subset of tests determined programmatically at runtime with gtest framework

这是正交的原因,但为了清楚起见:我创建了一个 TimeMonitor 事件监听器,它在测试结束时将经过的时间与策略进行比较,如果测试花费的时间更长,则失败。

它工作得很好,但有一个例外——系统有时会进入奇怪的状态,一些测试可能因此需要更长的时间。请注意,我的单元测试标准是 15 毫秒 - 这并不难发生。

我以前有过这个问题,我解决它的方法是创建一个记录,等到同一个测试多次超过它们,然后我才不及格。这有几个流程 - 主要流程 - 需要持久化数据。

我认为如果我只做两遍(或更多遍)效果会更好。第一次我收集超过他们时间的测试,并在第 2-N 次重复他们以确认或拒绝问题。

我的问题是 - 如何。我需要做什么(如果可能)以编程方式收集测试子集并重新运行它们。我需要从 testing::UnitTest::GetInstance() 中删除测试还是应该创建另一个 UnitTest.

参考类似的东西会很好,例如重试失败的测试。

我知道以下内容并未直接回答您的问题,但我相信提出不同方法的建议是合理的。我建议从一个单独的进程进行测试执行时间分析以简化事情并避免更改 运行 测试的程序。这样,您可以确定您没有通过插入附加代码来跟踪执行时间超过您定义的阈值的测试来影响测试的执行时间。此外,您将不需要修改 UnitTest 对象的状态和 googletest 实现的其他细节,这更难理解并且有潜在危险。

您的测试套件 运行 的可执行文件的输出已经为您提供了每个测试的执行时间。编写一个脚本,运行 将您的测试套件执行一次并解析该输出以确定哪些测试执行时间过长(这可以用一些更高级的语言轻松实现,例如 Python)。然后,如果脚本发现了一些可疑的测试,它会通过向它指定 --gtest_filter 命令行参数来重新 运行 测试套件可执行文件 2-N 次。例如:

tests.exe --gtest_filter=*test1*:*test2*:...:*testN*

这样,只有可疑的测试才会被重新运行,您将能够确定其中一些是否确实有问题。

如果您不想使用 googletest 提供的值,您可以修改 TimeMonitor 以输出测试执行时间并解析这些值。但是,也许最好删除它并 100% 确定您不会影响测试的执行时间。

希望对您有所帮助!

解决方案实际上很简单(当您知道时)。免责声明未针对所有可能的极端情况进行测试。

在伪代码中:

time monitor -> just observe and create a filter for the long tests
attach time monitor

testing::InitGoogleTest(&argc, argv);
int result = RUN_ALL_TESTS();

if (result == 0 && time_monitor->has too long tests()) {
    time monitor -> activate reporting errors
    ::testing::GTEST_FLAG(filter) =  time monitor -> the filter();
    result = RUN_ALL_TESTS();
}