gtest.lib 和 gtest_main.lib 有什么区别?
Google 的 C++ 测试框架有两个输出库:一个是 gtest.lib,另一个是 gtest_main.lib。根据 Nik Reiman 的回答 href="https://stackoverflow.com/questions/531941/how-to-setup-google-c-testing-framework-gtest-on-visual-studio-2005">如何使用 Visual Studio 设置 gtest,我们应该链接到 gtest_main.lib,但我链接到 gtest.lib 并且我拥有的示例测试用例运行良好。
这两个库之间有什么区别?链接到哪一个有什么关系吗?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
唯一合理的区别是 gtest_main.lib 提供了测试应用程序入口点的默认实现(即
main
函数):引用自 Google C++ 测试框架入门:
如果您想自己编写主要函数 - 您应该链接到 gtest.lib。
the only reasonable difference is that gtest_main.lib provides a default implementation of a test application entry point (i.e.
main
function):Citation from Getting started with Google C++ Testing Framework:
If you want to write your main function yourself - you should link with gtest.lib.
事实上,可用于 googletest 的各种构建方法并不能一致地构建库。至少这部分是一致的:
gtest
gtest 库(分别称为
gtest.a
、gtest.so
、gtest.lib
或libgtest.a
等,具体取决于您的平台以及您是否使用共享库)包含 gtest 框架的目标代码,包括测试所需的所有内容。基本上它实现了您可以从 gtest/gest.h 中使用的所有内容。它不包含main()
方法。gtest_main
它包含一个简单的 main 方法,该方法将启动已注册的测试,如下所示(从 1.8 开始):
现在不一致的部分是
gtest_main
有时还包含 < code>gtest,这样您只需需要链接到任一gtest
(如果您想编写自己的main()
方法) 或gtest_main
(如果您想使用上面的固定 main 方法)。例如,如果您使用 Makefile 构建,就是这种情况rel="noreferrer">googletest/make
:显然,
gtest_main.a
包含gtest.a
所做的一切,加上gtest-main.o
对象,其中包含 main 函数。然而,对于 CMake 构建,情况有所不同,至少对于某些构建工件而言是这样。例如,对于主要库我们有:
这里,
gtest_main
仅包含 main 函数,没有其他内容1。target_link_libraries
行告诉任何其他使用此 CMake 构建的内容,如果您链接gtest_main
,则还应该链接gtest
,因此在文件的其余部分中,通常会看到仅与gtest_main
链接的内容。事实上,CMakeLists.txt
文件中前面的文档明确说明了这一点:请注意“与其中一个”部分。他们真正的意思是,如果您使用相同的 CMake 系统进行构建,您可以做到这一点,但在实际的链接级别,您需要
libtest.a
和libgtest_main.a
否则你将无法提取编写测试所需的内容。1 事实上,使用 CMake libgtest.a 最终大小为 1,755,216 字节,而 libgtest_main.a 只有区区 3,836 字节。使用
../make/Makefile
构建时,这些数字分别为 3,365,240 和 3,398,356。显然,除了所包含的文件之外,还存在一些差异,这些差异会导致Makefile
版本的大小增大。In fact, the various build methods available for googletest don't build the libraries consistently. At least this part is consistent though:
gtest
The gtest library (variously called
gtest.a
,gtest.so
,gtest.lib
orlibgtest.a
, etc, depending on your platform and whether you are using the shared library) contains the object code for the gtest framework, including everything that tests need. Basically it implements everything you can use fromgtest/gest.h
. It does not include amain()
method.gtest_main
It includes a trivial main method that will launch the registered tests, something like this (as of 1.8):
Now the inconsistent part is that
gtest_main
sometimes also includes everything fromgtest
, so that you only need to link against eithergtest
(if you want to write your ownmain()
method) orgtest_main
(if you want the use the canned main method above). This is the case, for example, if you use theMakefile
build included ingoogletest/make
:Clearly,
gtest_main.a
includes everything thatgtest.a
does, plus thegtest-main.o
object which includes the main function.With the CMake build, however, the situation is different, at least for some build artifacts. For example, for the main libraries we have:
Here,
gtest_main
only contains the main function and nothing much else1. Thetarget_link_libraries
line tells anything else using this CMake build that if you linkgtest_main
you should also linkgtest
, so in the rest of the file it is common to see things linked only againstgtest_main
. Indeed, the documentation earlier in theCMakeLists.txt
file makes this explicit:Note the "with one one them" part. What they really mean is that if you are building with this same CMake system you can do that, but at the actual link level you need both
libtest.a
andlibgtest_main.a
or else you won't pull in what you need to write a test.1 Indeed, with CMake libgtest.a ends up at 1,755,216 bytes, and libgtest_main.a is only a paltry 3,836 bytes. With the
../make/Makefile
build, those figures are 3,365,240 and 3,398,356 respectively. Evidently there are differences beyond the files included that blow up the size of theMakefile
version.您需要使用单元测试将
gtest.lib
链接到您的项目。You will need to link
gtest.lib
to your project with the unit tests.