From what I understand gmock (and I'm new to it) EXPECT_CALL
allows for specifying how a method will behave when it's called (in this case I'm mostly interested in what it will return). But I could just as well define the method explicitly with its body. Example:
class Factory
{
int createSomething();
};
class MockFactory : public Factory
{
MOCK_METHOD0(createSomething, int());
};
int main()
{
...
int something(5);
MockFactory mockFactory;
EXPECT_CALL(mockFactory, createSomething()).WillRepeatedly(Return(something));
...
}
vs
class MockFactory : public Factory
{
int createSomething()
{
return 5;
}
};
Now, if createSomething
were to behave differently (return different things) in different scenarios then obviously I should use EXPECT_CALL
. But if it's going to always return the same thing wouldn't it be better to just explicitly define the method's body? (Note that other methods in the mocked class might still use EXPECT_CALL
.)
When you define a method you miss all the flexibility that mocking that method can give you in the tests.
If you need to assert in a test that
createSomething
gets called, you can only do it if you have mocked it, not if you have a standard method definition. Not in this case, but in case of methods taking parameters, it's even better to have a mock.If you need to set up a default action that your method should perform, even when you don't set any expectations on it, do so using
ON_CALL
macro in theSetUp
member function of aTestFixture
.