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

Repeat subset of tests determined programmatically at runtime with gtest framework

本文关键字：子集 测试 方式重 编程 框架 gtest 运行时 使用      更新时间：2023-10-16

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

它工作得很好，但有一个例外——系统有时会处于奇怪的状态，因此一些测试可能需要更长的时间。请注意，我的单元测试标准是15ms——这并不难实现。

我以前遇到过这种情况，我解决这个问题的方法是创建一个记录，直到同一个测试超过它们几次，我才失败。这有几个流程-主要的一个-需要持久化数据。

我认为如果我只做两次（或更多）传球，效果会更好。在第一次通过时，我收集超过时间的测试，在第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();
}
相关文章：