Home » C++ » Is Google Mock a good mocking framework? [closed]

Is Google Mock a good mocking framework? [closed]

Posted by: admin November 30, 2017 Leave a comment

Questions:

I am pioneering unit testing efforts at my company, and need need to choose a mocking framework to use. I have never used a mocking framework before. We have already chosen Google Test, so using Google Mock would be nice. However, my initial impressions after looking at Google Mock’s tutorial are:

  • The need for re-declaring each method in the mocking class with a MOCK_METHODn macro seems unnecessary and seems to go against the DRY principle.
  • Their matchers (eg, the ‘_’ in EXPECT_CALL(turtle, Forward(_));) and the order of matching seem almost too powerful. Like, it would be easy to say something you don’t mean, and miss bugs that way.

I have high confidence in google’s developers, and low confidence in my own ability to judge mocking frameworks, never having used them before. So my question is: Are these valid concerns?

Or is there no better way to define a mock object, and are the matchers intuitive to use in practice? I would appreciate answers from anyone who has used Google Mock before, and comparisons to other C++ frameworks would be helpful.

Answers:

I use it frequently.

It’s trivial to do relatively easy things, and possible to do very difficult things – that’s pretty much what I want from a framework.

The hardest part about writing custom Matchers (and other stuff) with Google’s mocks isn’t Google’s mocks, it’s C++’s template errors… they’re close to impossible to parse. I often write complex expressions by incrementally building a working expression from a few less complicated expressions. That way, the template errors are easier to pinpoint.

I haven’t seen a better option for c++ mocking, and Google’s covers a lot of ground, so I’d suggest you give it a shot.

WRT the DRY principle, I agree the declaring the mocked methods is unfortunate, but without reflection, I’m not sure c++ would have much luck otherwise. I’m near certain if there were a way, googlemock would be using it 😉

BTW: The googlemock cookbook is a good reference.

Questions:
Answers:

Fake-It is a simple mocking framework for C++. FakeIt uses the latest C++11 features to create an expressive (yet very simple) API.
With FakeIt there is no need for re-declaring methods nor creating a derived class for each mock.
Here is how you Fake-It:

struct SomeInterface {
  virtual int foo(int) = 0;
};

// That's all you have to do to create a mock.
Mock<SomeInterface> mock; 

// Stub method mock.foo(any argument) to return 1.
When(Method(mock,foo)).Return(1);

// Fetch the SomeInterface instance from the mock.
SomeInterface &i = mock.get();

// Will print "1"
cout << i.foo(10);

There are many more features to explore. Go ahead and give it a try.

Questions:
Answers:

Disclaimer: I wrote HippoMocks.

I can recommend looking at other mocking frameworks; there’s a class of them that don’t make you repeat yourself. They also do away with a new syntax for matching making your code read much more like C++ combined with English. Give it a try!

http://www.assembla.com/wiki/show/hippomocks

Questions:
Answers:

I’ve been using googletest + googlemock professionally for a few years, and I definitely like it. One thing that hasn’t been mentioned by others is that if you’re already committed to using googletest then it makes a lot of sense to also use googlemock. They’re fairly well integrated and shared a similar design style and philosophy, which is nice.

For example, googlemock provides ASSERT_THAT() macros which are super-useful, and coexist nicely with googletests’ assertions.

I would caution you about abusing the power of googlemock, however. It can be extremely tempting to write very complex & powerful matchers that end up being totally unreadable. You just need to be disciplined when using it.

Some other thoughts:

  • Googlemock can have a somewhat steep learning curve; the intricacies of matchers and expectations are not as straight-forward as you might hope.
  • The concern about violating DRY is valid; it’s annoying to have to manually define mocks when it seems like they could be easily auto-generated. It’s fairly common for teams to write their own code generators that automatically define googlemocks for their interfaces.