Open James-Tyne opened 5 months ago
It would be awkward for my real setup, but I could see an argument that a fake be used instead of a mock in this case. (It's awkward for me because that would mean splitting the interface; part of my interface is used in equality checking while another part is under test.) If the official stance is that a mock should not be used in this way, please consider this a feature request for better feedback from the test. With this indirect setup, it is not easy to see why a test deadlocks. However, it should not be hard for GoogleTest to detect this situation and emit a test failure instead of freezing.
Describe the issue
A test started freezing after a code change. I traced it to a recursive attempt to lock a mutex (and simplified the code to reproduce).
Picture this scenario:
There is a class that holds a pointer to an interface. Equality between objects of this class is defined in part by data obtained from this interface, such as getting an ID number of the interface implementation. There is also a second class that interacts with the first class. More precisely, the second class has a member function whose parameter is the first class.
Now picture a test suite for the second class. Since the first class is "just" support, it gets mocked in these tests. More precisely, the interface gets mocked. One of the tests in the suite expects that a certain mock will be provided to the member function as a parameter. No special matchers, just simple equality. However, this hangs when the function is called.
Steps to reproduce the problem
What version of GoogleTest are you using?
1.14.0
What operating system and version are you using?
Linux
What compiler and version are you using?
gcc version 11.4.1
What build system are you using?
cmake version 3.26.5
Additional context
No response