Clarification on interleaving of EXPECT_CALL()s and calls to mock functions in the case of multiple mocks

[bpartemis]

Hi all. I'm looking for clarification on the conclusion of this issue: #2828 (comment)

Its unclear to me if this constraint applies in a case where a gtest is using multiple mock class objects. Specifically the following scenario:

1. One creates two separate mock objects in a test, mockObjectA and mockObjectB, sets expectations on mockObjectA methods, then makes a call to a UUT (unit under test) method, ClassUnderTest.methodA(), such that that the mockObjectA method is called.
2. Following the call to ClassUnderTest.methodA(), expectations are set on a mockObjectB method and another call is made, this time to ClassUnderTest.methodB() which results in a call to the mockObjectB method. For example (using release 1.8.0 mock syntax):

class MockA{

    MOCK_METHOD0(getThisInternalState, int());

}

class MockB{

    MOCK_METHOD0(getThatInternalState, int());

}

class ClassUnderTest{

ClassUnderTest(MockA& inMockA, MockB& inMockB);

void methodA();

void methodB();

}

TEST_F(ExampleMockTest, ExampleTest){

MockA mockA;

MockB mockB;

ClassUnderTest classUnderTest(mockA, mockB);

EXPECT_CALL(mockA, getThisInternalState())
.Times(1);

classUnderTest.methodA();

EXPECT_CALL(mockB, getThatInternalState())
.Times(1);

classUnderTest.methodB();

}

The code example is simplified, please let me know if any additional detail or clarification is needed. Does this stray in the realm of undefined behavior?

Apologies if this question has already been covered elsewhere. I did what I felt was a relatively exhaustive search both in this github project and on SO and didn't find anything.

[Mahiuha]

The scenario you described is a valid usage of multiple mock objects in a gtest. You are creating two separate mock objects, mockObjectA and mockObjectB, setting expectations on their methods, and making calls to the ClassUnderTest methods, methodA() and methodB(). The calls to the mock objects' methods will only occur if the corresponding ClassUnderTest methods are called, as you have set the expectations for these calls. It does not stray into the realm of undefined behavior.

[bpartemis]

Thank you for clarifying!

One follow up if you don't mind. What about a scenario where there is second mock method in MockA, getThisOtherInternalState(), that is called by ClassUnderTest::methodC(). The test is the same as the first except after the ClassUnderTest::methodB() call we set expectations on the second MockA mock method, then call ClassUnderTest::methodC(). Is the interleaving of EXPECT_CALL()s and calls to mock functions constraint violated in this case?

Simplified code example illustrating this case:

class MockA{

MOCK_METHOD0(getThisInternalState, int());
MOCK_METHOD0(getThisOtherInternalState, int());

}

class MockB{

MOCK_METHOD0(getThatInternalState, int());

}

class ClassUnderTest{

ClassUnderTest(MockA& inMockA, MockB& inMockB);

void methodA();

void methodB();

void methodC();

}

TEST_F(ExampleMockTest, ExampleTest){

MockA mockA;

MockB mockB;

ClassUnderTest classUnderTest(mockA, mockB);

EXPECT_CALL(mockA, getThisInternalState())
.Times(1);

classUnderTest.methodA();

EXPECT_CALL(mockB, getThatInternalState())
.Times(1);

classUnderTest.methodB();

EXPECT_CALL(mockA, getThisOtherInternalState())
.Times(1);

classUnderTest.methodC();

}

[Mahiuha]

This scenario is still valid and should not result in undefined behavior as long as the expectations set in the test are met. In this case, the first call to ClassUnderTest.methodA() is expected to call the mockA.getThisInternalState() method once, the second call to ClassUnderTest.methodB() is expected to call the mockB.getThatInternalState() method once, and the third call to ClassUnderTest.methodC() is expected to call the mockA.getThisOtherInternalState() method once. As long as these expectations are met, the test should pass.
It's important to note that the order of the function calls matters, if the order is changed the test will fail.
It's also good practice to make sure that the test is clear and easy to read and understand, so it's a good idea to make sure that the test case is well-organized and clearly documents the expected behavior of the system under test.