gri*_*fcj 5 c++ googletest googlemock
我正在寻找通过 googletest 缩短构建时间的策略，并且想知道我所看到的是否是典型的，是否有可以避免的特定功能来缩短构建时间，或者我是否只是做错了什么。
我看过这篇文章，但现在已经有两年了。
我一直在使用一个相当简单的测试装置进行分析，该装置有 24 个测试并使用以下 googlemock 功能。我很抱歉无法在这里提供完整的示例，但显然对于简单的示例，构建时间可以忽略不计。如果您对此主题有经验并且有预感，我当然可以根据要求填写更多详细信息。总共，构建大约有 37 个文件，包括 googletest 源代码。
using ::testing::_;
using ::testing::AnyNumber;
using ::testing::DoAll;
using ::testing::Exactly;
using ::testing::InSequence;
using ::testing::Mock;
using ::testing::NiceMock;
using ::testing::Return;
using ::testing::SetArgReferee;
我已经使用 cmake 和 ninja 使用 clang 3.7.0 和 mingw64-g++ 5.3.0 构建了我的示例。请参阅下面的时间。项目中的所有源（包括 googletest）都需要完整的构建时间。编译+链接是构建单个测试装置源和链接所需的时间。链接是创建测试可执行文件的时间。我尝试了元组标志，但正如您所看到的，这没有多大区别。
随着时代的发展，它们对保持修复/构建/测试周期的快速进行提出了一些挑战。对我来说有趣的是，配置产生了如此巨大的差异，并且发布比调试更快。我预计发布会花更多时间在优化上。
GTEST_USE_OWN_TR1_TUPLE=1
Compiler | Config | Full | Compile+Link | Link
clang | Debug | 29.975s | 16.166s | 10.046s
clang | Release | 29.621s | 13.317s | 0.972s
mingw64 | Debug | 1m6.751s | 39.590s | 22.923s
mingw64 | Release | 44.287s | 15.075s | 1.031s
GTEST_USE_OWN_TR1_TUPLE=0
Compiler | Config | Full | Compile+Link | Link
clang | Debug | 28.565s | 15.815s | 9.545s
clang | Release | 28.354s | 12.955s | 1.075s
mingw64 | Debug | 1m7.954s | 37.611s | 24.304s
mingw64 | Release | 42.615s | 15.329s | 0.895s
进一步剖析发布 clang 构建的构建时间
#include <gmock/gmock.h> ~ 2s
Instantiating 11 mocks ~ 9s
24 test cases ~ 1s
编辑：
我遵循了食谱中的建议- 让编译更快，这很有帮助。我还与release-1.6.0进行了比较。我不知道关于多快才足够快（0秒，-2秒，时间旅行？）的共识是什么。不到10秒我开始感觉还可以忍受，5秒当然是首选。理想情况下，我希望将此示例缩短 1 秒，但也许这是不可能的。鉴于这是一个相当简单的例子，我的预感是事情不会在规模下成立，但也许事实并非如此。
googlemock 1.7+ ddb8012
GTEST_USE_OWN_TR1_TUPLE=0
Compiler | Config | Full | Compile+Link | Link
clang | Debug | 31.151s | 7.572s | 4.567s
clang | Release | 39.806s | 4.742s | 0.689s
googlemock 1.6
GTEST_USE_OWN_TR1_TUPLE=0
Compiler | Config | Full | Compile+Link | Link
clang | Debug | 26.551s | 5.104s | 3.218s
clang | Release | 28.932s | 3.777s | 0.676s