Question

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

友情链接