gtest_main does not discover any tests on Windows (Visual Studio)

[kraiskil]

I am using googletest in my project without problems on Linux (Ubuntu 16.04, 18.04) and Mac.
Now porting the same source to Windows (Visual Studio 15 2017), my googletest binary doesn't find any tests:

 Running main() from gtest_main.cc 
[==========] Running 0 tests from 0 test cases. 
[==========] 0 tests from 0 test cases ran. (1 ms total)
[  PASSED  ] 0 tests.

(same if I link in gmock_main instead of gtest_main).
Now, if I compile in a separate main.cpp:

#include <gmock/gmock.h>
int main(int argc, char *argv[]) {
    testing::InitGoogleTest(&argc, argv);
    testing::InitGoogleMock(&argc, argv);
    return RUN_ALL_TESTS();
}

instead of the one provided in gtest_main or gmock_main libraries everything works.

I'm using CMake to build my project, and I don't set any googletest specific settings except
-DGTEST_LINKED_AS_SHARED_LIBRARY

Tested with versions master branch versions 98a0d00 and efecb0b

[gennadiycivil]

I don't see any community activity on this issue. We don't use Visual Studio and not in position to help.

[kraiskil]

We don't use Visual Studio and not in position to help.

Just as a clarification: by Visual Studio I meant the C++ compiler that comes with Visual Studio, run from cmd.exe via CMake. No GUIs involved.

But since the rest of googletest works fine for me, please consider this more of a bug report than help request. And a hint for anyone hitting the same problem in the future!

[AaronBallman]

I've run into the same issue and found that linking in gmock is what seems to cause the issue for me, and only when compiling with Visual Studio. My CMake looks (partially) like:

target_link_libraries(
  ${PROJECT_NAME} ${SYSLIBS} gtest gmock gtest_main OtherLibName
)

When I run the tests with that link command, I get:

Running main() from C:\Users\aballman\Desktop\sandboxes\project_build\googletest-src\googletest\src\gtest_main.cc
[==========] Running 0 tests from 0 test suites.
[==========] 0 tests from 0 test suites ran. (0 ms total)
[  PASSED  ] 0 tests.

When I remove gmock from the link libraries (and remove gmock features from the affected tests), I get this behavior:

Running main() from C:\Users\aballman\Desktop\sandboxes\project_build\googletest-src\googletest\src\gtest_main.cc
[==========] Running 2 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 1 test from Swapping
[ RUN      ] Swapping.Stuff
[       OK ] Swapping.Stuff (0 ms)
[----------] 1 test from Swapping (1 ms total)

[----------] 1 test from Splitting
[ RUN      ] Splitting.split
[       OK ] Splitting.split (0 ms)
[----------] 1 test from Splitting (1 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 2 test suites ran. (7 ms total)
[  PASSED  ] 2 tests.

[AaronBallman]

FWIW, linking against gmock_main instead of gtest_main exhibits the same behavior. The only solution I've found was to manually add a main() as in the original comment.

[andre-nguyen]

@AaronBallman Thanks for the tip, I was going crazy trying to find the source of the problem. I'm getting the same problem with:

• IDE: CLion 2020.1.3
• Toolchain: MSbuild 2019
• CMake 3.18.0
• Googletest: a781fe2 (basically latest master at time of writing)

Fortunately my project doesn't use gmock but this is still puzzling as I don't think it happens under linux.

[spiralsam]

If you're using vcpkg: I've just run into this problem, but I'm using gtest as packaged by vcpkg, so the problem may be some combination of gtest/vcpkg bug. There's some pre-discussion here but I've found this by brute force: tediously stepping through (F10) debug, looking at GTest source, and checking MSVC linker verbose logs (Property Pages -> Linker -> All Options -> Show Progress = /VERBOSE):

Conclusion: These 3 dll's, as compiled on Windows vcpkg/gtest, are not compatible and none should not be linked with one of the other: gtestd.dll, gmockd.dll and gmockd_main.dll.

(For some reason on my vcpkg gtest v1.10.0, gtest_maind.dll depends on gtestd.dll, but gmockd_main.dll doesn't depend on gmockd.dll (test with dumpbin.exe /dependents). I assume it statically compiles gmockd.dll completely into itself, instead). I also reference the debug dll but presumably same is true for release dlls.

What I mean by "not compatible": although they each share exported symbols names, they have their own dll-global variables that work with the tests set up by TEST_F (specifically looked at the test_suites_ variable in googletest/src/gteste-internal-inl.h). If the application calls TEST_F (as expanded from the macro to eventually call MakeAndRegisterTestInfo from gtest.cc) from inside gmockd.dll, then calls main from gmock_maind.dll, they're not looking at the same internal variables. (check which exe/dll the program is currently in from Call Stack or Threads tool window, and then "&test_suites_" in a Debug -> Window -> Memory window).

I can't say if that's how gtest is compiled outside of vcpkg, so it may not solve your situation (if not using vcpkg) but can help; all I know is that by my setup's vcpkg default, my .exe had been picking up symbols from gmockd.dll from the TEST_F call, then calling into gtestd.dll from gtest_maind.dll by linking the latter explicitly. This is apparently happening due to two things: 1) the linker finds exported symbol names that it's looking for in an available .lib during library search on a first-found-first-taken basis; 2) link order causes some .lib/.dll mixing and mismatch mentioned above, when symbols are spread across different .libs. (with vcpkg, the search 1.10.0 directory contains both gmockd.dll and gtestd.dll ready to be picked up in alphabetical order; also, adding #pragma comment(lib ...) to a source file puts it at the end of the search chain, so this can have unexpected result).

Cliff notes: if your setup is compiled/installed as they are similar to vcpkg as of this writing, then link using only one of the following cases:
1) BOTH gtestd.lib and gtest_maind.lib; or
2) ONLY gmock_maind.lib

and put them in the Property Pages -> Linker -> Input, so they are put at the beginning of the search chain (or whatever equivalent does that for target_link_libraries)
The goal is to not have more than 1 of: gtestd.dll, gmockd.dll, gmock_maind.dll.

Otherwise, excluding gtestd.dll in case (1) can wrongly mix in gmockd.dll if it's also locateable in linker's search path. Likewise, adding gmockd.dll to case (2) is also a wrongful mixing, due to how it's compiled.

[joechanson]

Thanks @spiralsam ! I spent most of today with this problem and came across many other suggestions whilst searching the web but yours was the one that fixed my issue.

[venkatapathiraju]

Excellent @spiralsam , Have been struggling for some days with this issue and your solution fixed like magic.

[DeveloperPaul123]

We are still facing this issue and it's not clear to me what should be done in the case where gmock is needed. As mentioned above, if I remove gmock from list of libraries to link, gtest_main is able to discover the tests properly.

[ghost]

@DeveloperPaul123

I'm not sure if this helps
But, I'm using gtest and gmock as below in Visual Studio + CMake + vcpkg(gtest installed)

As far as I know, gtest_main or gmock_main are just for adding main() automatically
And so if you have a problem while using one of them, not using it can be a temporary solution
because there is no difference except whether there is main() or not

---

link gtest and gmock instead of gtest_main or gmock_main

...
find_package(GTest 1.10.0 CONFIG REQUIRED)

add_executable(mytest mytest.cpp)
target_link_libraries(mytest PRIVATE GTest::gtest GTest::gmock)

define main() in test code

...
int main(int argc, char **argv)
{
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

[DeveloperPaul123]

Thanks @hyukmyeong I guess I was hoping on some more movement to actually get this issue resolved but I found a workaround for our use case.

[adam4813]

Just ran into this, the default output when installing via vcpkg lists GTest::gmock as the first item, but if you move it to the last item it works as expected

target_link_libraries(MyTarget PRIVATE GTest::gmock GTest::gtest GTest::gmock_main GTest::gtest_main) # doesn't find tests

vs

target_link_libraries(MyTarget PRIVATE GTest::gtest GTest::gmock_main GTest::gtest_main GTest::gmock) # works and finds tests

Follow-up
After some tinkering it turns out to get Visual Studio's Test Explorer to see the tests you must only link gtest itself target_link_libraries(MyTarget PRIVATE GTest::gtest GTest::gtest_main), no mocking can be linked.

[sergeibobyr]

VS 2019, vcpkg in manifest mode, relevant dependencies: gtest, approval-tests-cpp. I'm not using my own main(). Each test cpp starts with:

#include "gmock/gmock.h"
#define APPROVALS_GOOGLETEST
#include "ApprovalTests.hpp"
...

I'm using in the test code: MOCK_METHOD(), INSTANTIATE_TEST_SUITE_P(), TEST_P().

I previously had NuGet gmock installed that was all pure source code, I had it compiled into a static lib that was linked into each test exe. All was working fine including test discovery via the test explorer in VS. When I decided to move to vcpkg version of gtest I encountered two issues:

1). Error LNK2001 unresolved external symbol "class testing::internal::Mutex testing::internal::g_gmock_mutex" - this was fixed by adding GTEST_LINKED_AS_SHARED_LIBRARY preprocessor definition.

2). Tests disappeared from the test explorer. The build succeeds, I can run each test exe just fine. Each test exe can be invoked with --gtest_list_tests just fine and all tests are listed but test explorer finds no tests. What solved it for me was to change the vckpg 'auto-link' property to 'no' - it would now, as expected, fail to link. Then, what really matters for test explorer discovery is the order of gtest.lib and gmock.lib. If I specify "gtest.lib;gmock.lib" - test explorer can discover all the tests. The opposite order leads to no tests discovered.

[Shawn1874]

Since upgrading from google test 1.8 to 1.13, I am now experiencing this issue using Visual Studio 2019 v16.11.20. My experience is the same as others who are also using gmock. In other projects that do not use gmock, this is not an issue. For now I'll have to just manually define a main function. This seems like a defect with google test that was introduced since v1.8.