FrequentlyAskedQuestions.md revision 13481
113481Sgiacomo.travaglini@arm.com 213481Sgiacomo.travaglini@arm.com 313481Sgiacomo.travaglini@arm.comPlease send your questions to the 413481Sgiacomo.travaglini@arm.com[googlemock](http://groups.google.com/group/googlemock) discussion 513481Sgiacomo.travaglini@arm.comgroup. If you need help with compiler errors, make sure you have 613481Sgiacomo.travaglini@arm.comtried [Google Mock Doctor](#How_am_I_supposed_to_make_sense_of_these_horrible_template_error.md) first. 713481Sgiacomo.travaglini@arm.com 813481Sgiacomo.travaglini@arm.com## I wrote some matchers. After I upgraded to a new version of Google Mock, they no longer compile. What's going on? ## 913481Sgiacomo.travaglini@arm.com 1013481Sgiacomo.travaglini@arm.comAfter version 1.4.0 of Google Mock was released, we had an idea on how 1113481Sgiacomo.travaglini@arm.comto make it easier to write matchers that can generate informative 1213481Sgiacomo.travaglini@arm.commessages efficiently. We experimented with this idea and liked what 1313481Sgiacomo.travaglini@arm.comwe saw. Therefore we decided to implement it. 1413481Sgiacomo.travaglini@arm.com 1513481Sgiacomo.travaglini@arm.comUnfortunately, this means that if you have defined your own matchers 1613481Sgiacomo.travaglini@arm.comby implementing `MatcherInterface` or using `MakePolymorphicMatcher()`, 1713481Sgiacomo.travaglini@arm.comyour definitions will no longer compile. Matchers defined using the 1813481Sgiacomo.travaglini@arm.com`MATCHER*` family of macros are not affected. 1913481Sgiacomo.travaglini@arm.com 2013481Sgiacomo.travaglini@arm.comSorry for the hassle if your matchers are affected. We believe it's 2113481Sgiacomo.travaglini@arm.comin everyone's long-term interest to make this change sooner than 2213481Sgiacomo.travaglini@arm.comlater. Fortunately, it's usually not hard to migrate an existing 2313481Sgiacomo.travaglini@arm.commatcher to the new API. Here's what you need to do: 2413481Sgiacomo.travaglini@arm.com 2513481Sgiacomo.travaglini@arm.comIf you wrote your matcher like this: 2613481Sgiacomo.travaglini@arm.com``` 2713481Sgiacomo.travaglini@arm.com// Old matcher definition that doesn't work with the latest 2813481Sgiacomo.travaglini@arm.com// Google Mock. 2913481Sgiacomo.travaglini@arm.comusing ::testing::MatcherInterface; 3013481Sgiacomo.travaglini@arm.com... 3113481Sgiacomo.travaglini@arm.comclass MyWonderfulMatcher : public MatcherInterface<MyType> { 3213481Sgiacomo.travaglini@arm.com public: 3313481Sgiacomo.travaglini@arm.com ... 3413481Sgiacomo.travaglini@arm.com virtual bool Matches(MyType value) const { 3513481Sgiacomo.travaglini@arm.com // Returns true if value matches. 3613481Sgiacomo.travaglini@arm.com return value.GetFoo() > 5; 3713481Sgiacomo.travaglini@arm.com } 3813481Sgiacomo.travaglini@arm.com ... 3913481Sgiacomo.travaglini@arm.com}; 4013481Sgiacomo.travaglini@arm.com``` 4113481Sgiacomo.travaglini@arm.com 4213481Sgiacomo.travaglini@arm.comyou'll need to change it to: 4313481Sgiacomo.travaglini@arm.com``` 4413481Sgiacomo.travaglini@arm.com// New matcher definition that works with the latest Google Mock. 4513481Sgiacomo.travaglini@arm.comusing ::testing::MatcherInterface; 4613481Sgiacomo.travaglini@arm.comusing ::testing::MatchResultListener; 4713481Sgiacomo.travaglini@arm.com... 4813481Sgiacomo.travaglini@arm.comclass MyWonderfulMatcher : public MatcherInterface<MyType> { 4913481Sgiacomo.travaglini@arm.com public: 5013481Sgiacomo.travaglini@arm.com ... 5113481Sgiacomo.travaglini@arm.com virtual bool MatchAndExplain(MyType value, 5213481Sgiacomo.travaglini@arm.com MatchResultListener* listener) const { 5313481Sgiacomo.travaglini@arm.com // Returns true if value matches. 5413481Sgiacomo.travaglini@arm.com return value.GetFoo() > 5; 5513481Sgiacomo.travaglini@arm.com } 5613481Sgiacomo.travaglini@arm.com ... 5713481Sgiacomo.travaglini@arm.com}; 5813481Sgiacomo.travaglini@arm.com``` 5913481Sgiacomo.travaglini@arm.com(i.e. rename `Matches()` to `MatchAndExplain()` and give it a second 6013481Sgiacomo.travaglini@arm.comargument of type `MatchResultListener*`.) 6113481Sgiacomo.travaglini@arm.com 6213481Sgiacomo.travaglini@arm.comIf you were also using `ExplainMatchResultTo()` to improve the matcher 6313481Sgiacomo.travaglini@arm.commessage: 6413481Sgiacomo.travaglini@arm.com``` 6513481Sgiacomo.travaglini@arm.com// Old matcher definition that doesn't work with the lastest 6613481Sgiacomo.travaglini@arm.com// Google Mock. 6713481Sgiacomo.travaglini@arm.comusing ::testing::MatcherInterface; 6813481Sgiacomo.travaglini@arm.com... 6913481Sgiacomo.travaglini@arm.comclass MyWonderfulMatcher : public MatcherInterface<MyType> { 7013481Sgiacomo.travaglini@arm.com public: 7113481Sgiacomo.travaglini@arm.com ... 7213481Sgiacomo.travaglini@arm.com virtual bool Matches(MyType value) const { 7313481Sgiacomo.travaglini@arm.com // Returns true if value matches. 7413481Sgiacomo.travaglini@arm.com return value.GetFoo() > 5; 7513481Sgiacomo.travaglini@arm.com } 7613481Sgiacomo.travaglini@arm.com 7713481Sgiacomo.travaglini@arm.com virtual void ExplainMatchResultTo(MyType value, 7813481Sgiacomo.travaglini@arm.com ::std::ostream* os) const { 7913481Sgiacomo.travaglini@arm.com // Prints some helpful information to os to help 8013481Sgiacomo.travaglini@arm.com // a user understand why value matches (or doesn't match). 8113481Sgiacomo.travaglini@arm.com *os << "the Foo property is " << value.GetFoo(); 8213481Sgiacomo.travaglini@arm.com } 8313481Sgiacomo.travaglini@arm.com ... 8413481Sgiacomo.travaglini@arm.com}; 8513481Sgiacomo.travaglini@arm.com``` 8613481Sgiacomo.travaglini@arm.com 8713481Sgiacomo.travaglini@arm.comyou should move the logic of `ExplainMatchResultTo()` into 8813481Sgiacomo.travaglini@arm.com`MatchAndExplain()`, using the `MatchResultListener` argument where 8913481Sgiacomo.travaglini@arm.comthe `::std::ostream` was used: 9013481Sgiacomo.travaglini@arm.com``` 9113481Sgiacomo.travaglini@arm.com// New matcher definition that works with the latest Google Mock. 9213481Sgiacomo.travaglini@arm.comusing ::testing::MatcherInterface; 9313481Sgiacomo.travaglini@arm.comusing ::testing::MatchResultListener; 9413481Sgiacomo.travaglini@arm.com... 9513481Sgiacomo.travaglini@arm.comclass MyWonderfulMatcher : public MatcherInterface<MyType> { 9613481Sgiacomo.travaglini@arm.com public: 9713481Sgiacomo.travaglini@arm.com ... 9813481Sgiacomo.travaglini@arm.com virtual bool MatchAndExplain(MyType value, 9913481Sgiacomo.travaglini@arm.com MatchResultListener* listener) const { 10013481Sgiacomo.travaglini@arm.com // Returns true if value matches. 10113481Sgiacomo.travaglini@arm.com *listener << "the Foo property is " << value.GetFoo(); 10213481Sgiacomo.travaglini@arm.com return value.GetFoo() > 5; 10313481Sgiacomo.travaglini@arm.com } 10413481Sgiacomo.travaglini@arm.com ... 10513481Sgiacomo.travaglini@arm.com}; 10613481Sgiacomo.travaglini@arm.com``` 10713481Sgiacomo.travaglini@arm.com 10813481Sgiacomo.travaglini@arm.comIf your matcher is defined using `MakePolymorphicMatcher()`: 10913481Sgiacomo.travaglini@arm.com``` 11013481Sgiacomo.travaglini@arm.com// Old matcher definition that doesn't work with the latest 11113481Sgiacomo.travaglini@arm.com// Google Mock. 11213481Sgiacomo.travaglini@arm.comusing ::testing::MakePolymorphicMatcher; 11313481Sgiacomo.travaglini@arm.com... 11413481Sgiacomo.travaglini@arm.comclass MyGreatMatcher { 11513481Sgiacomo.travaglini@arm.com public: 11613481Sgiacomo.travaglini@arm.com ... 11713481Sgiacomo.travaglini@arm.com bool Matches(MyType value) const { 11813481Sgiacomo.travaglini@arm.com // Returns true if value matches. 11913481Sgiacomo.travaglini@arm.com return value.GetBar() < 42; 12013481Sgiacomo.travaglini@arm.com } 12113481Sgiacomo.travaglini@arm.com ... 12213481Sgiacomo.travaglini@arm.com}; 12313481Sgiacomo.travaglini@arm.com... MakePolymorphicMatcher(MyGreatMatcher()) ... 12413481Sgiacomo.travaglini@arm.com``` 12513481Sgiacomo.travaglini@arm.com 12613481Sgiacomo.travaglini@arm.comyou should rename the `Matches()` method to `MatchAndExplain()` and 12713481Sgiacomo.travaglini@arm.comadd a `MatchResultListener*` argument (the same as what you need to do 12813481Sgiacomo.travaglini@arm.comfor matchers defined by implementing `MatcherInterface`): 12913481Sgiacomo.travaglini@arm.com``` 13013481Sgiacomo.travaglini@arm.com// New matcher definition that works with the latest Google Mock. 13113481Sgiacomo.travaglini@arm.comusing ::testing::MakePolymorphicMatcher; 13213481Sgiacomo.travaglini@arm.comusing ::testing::MatchResultListener; 13313481Sgiacomo.travaglini@arm.com... 13413481Sgiacomo.travaglini@arm.comclass MyGreatMatcher { 13513481Sgiacomo.travaglini@arm.com public: 13613481Sgiacomo.travaglini@arm.com ... 13713481Sgiacomo.travaglini@arm.com bool MatchAndExplain(MyType value, 13813481Sgiacomo.travaglini@arm.com MatchResultListener* listener) const { 13913481Sgiacomo.travaglini@arm.com // Returns true if value matches. 14013481Sgiacomo.travaglini@arm.com return value.GetBar() < 42; 14113481Sgiacomo.travaglini@arm.com } 14213481Sgiacomo.travaglini@arm.com ... 14313481Sgiacomo.travaglini@arm.com}; 14413481Sgiacomo.travaglini@arm.com... MakePolymorphicMatcher(MyGreatMatcher()) ... 14513481Sgiacomo.travaglini@arm.com``` 14613481Sgiacomo.travaglini@arm.com 14713481Sgiacomo.travaglini@arm.comIf your polymorphic matcher uses `ExplainMatchResultTo()` for better 14813481Sgiacomo.travaglini@arm.comfailure messages: 14913481Sgiacomo.travaglini@arm.com``` 15013481Sgiacomo.travaglini@arm.com// Old matcher definition that doesn't work with the latest 15113481Sgiacomo.travaglini@arm.com// Google Mock. 15213481Sgiacomo.travaglini@arm.comusing ::testing::MakePolymorphicMatcher; 15313481Sgiacomo.travaglini@arm.com... 15413481Sgiacomo.travaglini@arm.comclass MyGreatMatcher { 15513481Sgiacomo.travaglini@arm.com public: 15613481Sgiacomo.travaglini@arm.com ... 15713481Sgiacomo.travaglini@arm.com bool Matches(MyType value) const { 15813481Sgiacomo.travaglini@arm.com // Returns true if value matches. 15913481Sgiacomo.travaglini@arm.com return value.GetBar() < 42; 16013481Sgiacomo.travaglini@arm.com } 16113481Sgiacomo.travaglini@arm.com ... 16213481Sgiacomo.travaglini@arm.com}; 16313481Sgiacomo.travaglini@arm.comvoid ExplainMatchResultTo(const MyGreatMatcher& matcher, 16413481Sgiacomo.travaglini@arm.com MyType value, 16513481Sgiacomo.travaglini@arm.com ::std::ostream* os) { 16613481Sgiacomo.travaglini@arm.com // Prints some helpful information to os to help 16713481Sgiacomo.travaglini@arm.com // a user understand why value matches (or doesn't match). 16813481Sgiacomo.travaglini@arm.com *os << "the Bar property is " << value.GetBar(); 16913481Sgiacomo.travaglini@arm.com} 17013481Sgiacomo.travaglini@arm.com... MakePolymorphicMatcher(MyGreatMatcher()) ... 17113481Sgiacomo.travaglini@arm.com``` 17213481Sgiacomo.travaglini@arm.com 17313481Sgiacomo.travaglini@arm.comyou'll need to move the logic inside `ExplainMatchResultTo()` to 17413481Sgiacomo.travaglini@arm.com`MatchAndExplain()`: 17513481Sgiacomo.travaglini@arm.com``` 17613481Sgiacomo.travaglini@arm.com// New matcher definition that works with the latest Google Mock. 17713481Sgiacomo.travaglini@arm.comusing ::testing::MakePolymorphicMatcher; 17813481Sgiacomo.travaglini@arm.comusing ::testing::MatchResultListener; 17913481Sgiacomo.travaglini@arm.com... 18013481Sgiacomo.travaglini@arm.comclass MyGreatMatcher { 18113481Sgiacomo.travaglini@arm.com public: 18213481Sgiacomo.travaglini@arm.com ... 18313481Sgiacomo.travaglini@arm.com bool MatchAndExplain(MyType value, 18413481Sgiacomo.travaglini@arm.com MatchResultListener* listener) const { 18513481Sgiacomo.travaglini@arm.com // Returns true if value matches. 18613481Sgiacomo.travaglini@arm.com *listener << "the Bar property is " << value.GetBar(); 18713481Sgiacomo.travaglini@arm.com return value.GetBar() < 42; 18813481Sgiacomo.travaglini@arm.com } 18913481Sgiacomo.travaglini@arm.com ... 19013481Sgiacomo.travaglini@arm.com}; 19113481Sgiacomo.travaglini@arm.com... MakePolymorphicMatcher(MyGreatMatcher()) ... 19213481Sgiacomo.travaglini@arm.com``` 19313481Sgiacomo.travaglini@arm.com 19413481Sgiacomo.travaglini@arm.comFor more information, you can read these 19513481Sgiacomo.travaglini@arm.com[two](V1_5_CookBook#Writing_New_Monomorphic_Matchers.md) 19613481Sgiacomo.travaglini@arm.com[recipes](V1_5_CookBook#Writing_New_Polymorphic_Matchers.md) 19713481Sgiacomo.travaglini@arm.comfrom the cookbook. As always, you 19813481Sgiacomo.travaglini@arm.comare welcome to post questions on `googlemock@googlegroups.com` if you 19913481Sgiacomo.travaglini@arm.comneed any help. 20013481Sgiacomo.travaglini@arm.com 20113481Sgiacomo.travaglini@arm.com## When using Google Mock, do I have to use Google Test as the testing framework? I have my favorite testing framework and don't want to switch. ## 20213481Sgiacomo.travaglini@arm.com 20313481Sgiacomo.travaglini@arm.comGoogle Mock works out of the box with Google Test. However, it's easy 20413481Sgiacomo.travaglini@arm.comto configure it to work with any testing framework of your choice. 20513481Sgiacomo.travaglini@arm.com[Here](V1_5_ForDummies#Using_Google_Mock_with_Any_Testing_Framework.md) is how. 20613481Sgiacomo.travaglini@arm.com 20713481Sgiacomo.travaglini@arm.com## How am I supposed to make sense of these horrible template errors? ## 20813481Sgiacomo.travaglini@arm.com 20913481Sgiacomo.travaglini@arm.comIf you are confused by the compiler errors gcc threw at you, 21013481Sgiacomo.travaglini@arm.comtry consulting the _Google Mock Doctor_ tool first. What it does is to 21113481Sgiacomo.travaglini@arm.comscan stdin for gcc error messages, and spit out diagnoses on the 21213481Sgiacomo.travaglini@arm.comproblems (we call them diseases) your code has. 21313481Sgiacomo.travaglini@arm.com 21413481Sgiacomo.travaglini@arm.comTo "install", run command: 21513481Sgiacomo.travaglini@arm.com``` 21613481Sgiacomo.travaglini@arm.comalias gmd='<path to googlemock>/scripts/gmock_doctor.py' 21713481Sgiacomo.travaglini@arm.com``` 21813481Sgiacomo.travaglini@arm.com 21913481Sgiacomo.travaglini@arm.comTo use it, do: 22013481Sgiacomo.travaglini@arm.com``` 22113481Sgiacomo.travaglini@arm.com<your-favorite-build-command> <your-test> 2>&1 | gmd 22213481Sgiacomo.travaglini@arm.com``` 22313481Sgiacomo.travaglini@arm.com 22413481Sgiacomo.travaglini@arm.comFor example: 22513481Sgiacomo.travaglini@arm.com``` 22613481Sgiacomo.travaglini@arm.commake my_test 2>&1 | gmd 22713481Sgiacomo.travaglini@arm.com``` 22813481Sgiacomo.travaglini@arm.com 22913481Sgiacomo.travaglini@arm.comOr you can run `gmd` and copy-n-paste gcc's error messages to it. 23013481Sgiacomo.travaglini@arm.com 23113481Sgiacomo.travaglini@arm.com## Can I mock a variadic function? ## 23213481Sgiacomo.travaglini@arm.com 23313481Sgiacomo.travaglini@arm.comYou cannot mock a variadic function (i.e. a function taking ellipsis 23413481Sgiacomo.travaglini@arm.com(`...`) arguments) directly in Google Mock. 23513481Sgiacomo.travaglini@arm.com 23613481Sgiacomo.travaglini@arm.comThe problem is that in general, there is _no way_ for a mock object to 23713481Sgiacomo.travaglini@arm.comknow how many arguments are passed to the variadic method, and what 23813481Sgiacomo.travaglini@arm.comthe arguments' types are. Only the _author of the base class_ knows 23913481Sgiacomo.travaglini@arm.comthe protocol, and we cannot look into his head. 24013481Sgiacomo.travaglini@arm.com 24113481Sgiacomo.travaglini@arm.comTherefore, to mock such a function, the _user_ must teach the mock 24213481Sgiacomo.travaglini@arm.comobject how to figure out the number of arguments and their types. One 24313481Sgiacomo.travaglini@arm.comway to do it is to provide overloaded versions of the function. 24413481Sgiacomo.travaglini@arm.com 24513481Sgiacomo.travaglini@arm.comEllipsis arguments are inherited from C and not really a C++ feature. 24613481Sgiacomo.travaglini@arm.comThey are unsafe to use and don't work with arguments that have 24713481Sgiacomo.travaglini@arm.comconstructors or destructors. Therefore we recommend to avoid them in 24813481Sgiacomo.travaglini@arm.comC++ as much as possible. 24913481Sgiacomo.travaglini@arm.com 25013481Sgiacomo.travaglini@arm.com## MSVC gives me warning C4301 or C4373 when I define a mock method with a const parameter. Why? ## 25113481Sgiacomo.travaglini@arm.com 25213481Sgiacomo.travaglini@arm.comIf you compile this using Microsoft Visual C++ 2005 SP1: 25313481Sgiacomo.travaglini@arm.com``` 25413481Sgiacomo.travaglini@arm.comclass Foo { 25513481Sgiacomo.travaglini@arm.com ... 25613481Sgiacomo.travaglini@arm.com virtual void Bar(const int i) = 0; 25713481Sgiacomo.travaglini@arm.com}; 25813481Sgiacomo.travaglini@arm.com 25913481Sgiacomo.travaglini@arm.comclass MockFoo : public Foo { 26013481Sgiacomo.travaglini@arm.com ... 26113481Sgiacomo.travaglini@arm.com MOCK_METHOD1(Bar, void(const int i)); 26213481Sgiacomo.travaglini@arm.com}; 26313481Sgiacomo.travaglini@arm.com``` 26413481Sgiacomo.travaglini@arm.comYou may get the following warning: 26513481Sgiacomo.travaglini@arm.com``` 26613481Sgiacomo.travaglini@arm.comwarning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier 26713481Sgiacomo.travaglini@arm.com``` 26813481Sgiacomo.travaglini@arm.com 26913481Sgiacomo.travaglini@arm.comThis is a MSVC bug. The same code compiles fine with gcc ,for 27013481Sgiacomo.travaglini@arm.comexample. If you use Visual C++ 2008 SP1, you would get the warning: 27113481Sgiacomo.travaglini@arm.com``` 27213481Sgiacomo.travaglini@arm.comwarning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers 27313481Sgiacomo.travaglini@arm.com``` 27413481Sgiacomo.travaglini@arm.com 27513481Sgiacomo.travaglini@arm.comIn C++, if you _declare_ a function with a `const` parameter, the 27613481Sgiacomo.travaglini@arm.com`const` modifier is _ignored_. Therefore, the `Foo` base class above 27713481Sgiacomo.travaglini@arm.comis equivalent to: 27813481Sgiacomo.travaglini@arm.com``` 27913481Sgiacomo.travaglini@arm.comclass Foo { 28013481Sgiacomo.travaglini@arm.com ... 28113481Sgiacomo.travaglini@arm.com virtual void Bar(int i) = 0; // int or const int? Makes no difference. 28213481Sgiacomo.travaglini@arm.com}; 28313481Sgiacomo.travaglini@arm.com``` 28413481Sgiacomo.travaglini@arm.com 28513481Sgiacomo.travaglini@arm.comIn fact, you can _declare_ Bar() with an `int` parameter, and _define_ 28613481Sgiacomo.travaglini@arm.comit with a `const int` parameter. The compiler will still match them 28713481Sgiacomo.travaglini@arm.comup. 28813481Sgiacomo.travaglini@arm.com 28913481Sgiacomo.travaglini@arm.comSince making a parameter `const` is meaningless in the method 29013481Sgiacomo.travaglini@arm.com_declaration_, we recommend to remove it in both `Foo` and `MockFoo`. 29113481Sgiacomo.travaglini@arm.comThat should workaround the VC bug. 29213481Sgiacomo.travaglini@arm.com 29313481Sgiacomo.travaglini@arm.comNote that we are talking about the _top-level_ `const` modifier here. 29413481Sgiacomo.travaglini@arm.comIf the function parameter is passed by pointer or reference, declaring 29513481Sgiacomo.travaglini@arm.comthe _pointee_ or _referee_ as `const` is still meaningful. For 29613481Sgiacomo.travaglini@arm.comexample, the following two declarations are _not_ equivalent: 29713481Sgiacomo.travaglini@arm.com``` 29813481Sgiacomo.travaglini@arm.comvoid Bar(int* p); // Neither p nor *p is const. 29913481Sgiacomo.travaglini@arm.comvoid Bar(const int* p); // p is not const, but *p is. 30013481Sgiacomo.travaglini@arm.com``` 30113481Sgiacomo.travaglini@arm.com 30213481Sgiacomo.travaglini@arm.com## I have a huge mock class, and Microsoft Visual C++ runs out of memory when compiling it. What can I do? ## 30313481Sgiacomo.travaglini@arm.com 30413481Sgiacomo.travaglini@arm.comWe've noticed that when the `/clr` compiler flag is used, Visual C++ 30513481Sgiacomo.travaglini@arm.comuses 5~6 times as much memory when compiling a mock class. We suggest 30613481Sgiacomo.travaglini@arm.comto avoid `/clr` when compiling native C++ mocks. 30713481Sgiacomo.travaglini@arm.com 30813481Sgiacomo.travaglini@arm.com## I can't figure out why Google Mock thinks my expectations are not satisfied. What should I do? ## 30913481Sgiacomo.travaglini@arm.com 31013481Sgiacomo.travaglini@arm.comYou might want to run your test with 31113481Sgiacomo.travaglini@arm.com`--gmock_verbose=info`. This flag lets Google Mock print a trace 31213481Sgiacomo.travaglini@arm.comof every mock function call it receives. By studying the trace, 31313481Sgiacomo.travaglini@arm.comyou'll gain insights on why the expectations you set are not met. 31413481Sgiacomo.travaglini@arm.com 31513481Sgiacomo.travaglini@arm.com## How can I assert that a function is NEVER called? ## 31613481Sgiacomo.travaglini@arm.com 31713481Sgiacomo.travaglini@arm.com``` 31813481Sgiacomo.travaglini@arm.comEXPECT_CALL(foo, Bar(_)) 31913481Sgiacomo.travaglini@arm.com .Times(0); 32013481Sgiacomo.travaglini@arm.com``` 32113481Sgiacomo.travaglini@arm.com 32213481Sgiacomo.travaglini@arm.com## I have a failed test where Google Mock tells me TWICE that a particular expectation is not satisfied. Isn't this redundant? ## 32313481Sgiacomo.travaglini@arm.com 32413481Sgiacomo.travaglini@arm.comWhen Google Mock detects a failure, it prints relevant information 32513481Sgiacomo.travaglini@arm.com(the mock function arguments, the state of relevant expectations, and 32613481Sgiacomo.travaglini@arm.cometc) to help the user debug. If another failure is detected, Google 32713481Sgiacomo.travaglini@arm.comMock will do the same, including printing the state of relevant 32813481Sgiacomo.travaglini@arm.comexpectations. 32913481Sgiacomo.travaglini@arm.com 33013481Sgiacomo.travaglini@arm.comSometimes an expectation's state didn't change between two failures, 33113481Sgiacomo.travaglini@arm.comand you'll see the same description of the state twice. They are 33213481Sgiacomo.travaglini@arm.comhowever _not_ redundant, as they refer to _different points in time_. 33313481Sgiacomo.travaglini@arm.comThe fact they are the same _is_ interesting information. 33413481Sgiacomo.travaglini@arm.com 33513481Sgiacomo.travaglini@arm.com## I get a heap check failure when using a mock object, but using a real object is fine. What can be wrong? ## 33613481Sgiacomo.travaglini@arm.com 33713481Sgiacomo.travaglini@arm.comDoes the class (hopefully a pure interface) you are mocking have a 33813481Sgiacomo.travaglini@arm.comvirtual destructor? 33913481Sgiacomo.travaglini@arm.com 34013481Sgiacomo.travaglini@arm.comWhenever you derive from a base class, make sure its destructor is 34113481Sgiacomo.travaglini@arm.comvirtual. Otherwise Bad Things will happen. Consider the following 34213481Sgiacomo.travaglini@arm.comcode: 34313481Sgiacomo.travaglini@arm.com 34413481Sgiacomo.travaglini@arm.com``` 34513481Sgiacomo.travaglini@arm.comclass Base { 34613481Sgiacomo.travaglini@arm.com public: 34713481Sgiacomo.travaglini@arm.com // Not virtual, but should be. 34813481Sgiacomo.travaglini@arm.com ~Base() { ... } 34913481Sgiacomo.travaglini@arm.com ... 35013481Sgiacomo.travaglini@arm.com}; 35113481Sgiacomo.travaglini@arm.com 35213481Sgiacomo.travaglini@arm.comclass Derived : public Base { 35313481Sgiacomo.travaglini@arm.com public: 35413481Sgiacomo.travaglini@arm.com ... 35513481Sgiacomo.travaglini@arm.com private: 35613481Sgiacomo.travaglini@arm.com std::string value_; 35713481Sgiacomo.travaglini@arm.com}; 35813481Sgiacomo.travaglini@arm.com 35913481Sgiacomo.travaglini@arm.com... 36013481Sgiacomo.travaglini@arm.com Base* p = new Derived; 36113481Sgiacomo.travaglini@arm.com ... 36213481Sgiacomo.travaglini@arm.com delete p; // Surprise! ~Base() will be called, but ~Derived() will not 36313481Sgiacomo.travaglini@arm.com // - value_ is leaked. 36413481Sgiacomo.travaglini@arm.com``` 36513481Sgiacomo.travaglini@arm.com 36613481Sgiacomo.travaglini@arm.comBy changing `~Base()` to virtual, `~Derived()` will be correctly 36713481Sgiacomo.travaglini@arm.comcalled when `delete p` is executed, and the heap checker 36813481Sgiacomo.travaglini@arm.comwill be happy. 36913481Sgiacomo.travaglini@arm.com 37013481Sgiacomo.travaglini@arm.com## The "newer expectations override older ones" rule makes writing expectations awkward. Why does Google Mock do that? ## 37113481Sgiacomo.travaglini@arm.com 37213481Sgiacomo.travaglini@arm.comWhen people complain about this, often they are referring to code like: 37313481Sgiacomo.travaglini@arm.com 37413481Sgiacomo.travaglini@arm.com``` 37513481Sgiacomo.travaglini@arm.com// foo.Bar() should be called twice, return 1 the first time, and return 37613481Sgiacomo.travaglini@arm.com// 2 the second time. However, I have to write the expectations in the 37713481Sgiacomo.travaglini@arm.com// reverse order. This sucks big time!!! 37813481Sgiacomo.travaglini@arm.comEXPECT_CALL(foo, Bar()) 37913481Sgiacomo.travaglini@arm.com .WillOnce(Return(2)) 38013481Sgiacomo.travaglini@arm.com .RetiresOnSaturation(); 38113481Sgiacomo.travaglini@arm.comEXPECT_CALL(foo, Bar()) 38213481Sgiacomo.travaglini@arm.com .WillOnce(Return(1)) 38313481Sgiacomo.travaglini@arm.com .RetiresOnSaturation(); 38413481Sgiacomo.travaglini@arm.com``` 38513481Sgiacomo.travaglini@arm.com 38613481Sgiacomo.travaglini@arm.comThe problem is that they didn't pick the **best** way to express the test's 38713481Sgiacomo.travaglini@arm.comintent. 38813481Sgiacomo.travaglini@arm.com 38913481Sgiacomo.travaglini@arm.comBy default, expectations don't have to be matched in _any_ particular 39013481Sgiacomo.travaglini@arm.comorder. If you want them to match in a certain order, you need to be 39113481Sgiacomo.travaglini@arm.comexplicit. This is Google Mock's (and jMock's) fundamental philosophy: it's 39213481Sgiacomo.travaglini@arm.comeasy to accidentally over-specify your tests, and we want to make it 39313481Sgiacomo.travaglini@arm.comharder to do so. 39413481Sgiacomo.travaglini@arm.com 39513481Sgiacomo.travaglini@arm.comThere are two better ways to write the test spec. You could either 39613481Sgiacomo.travaglini@arm.comput the expectations in sequence: 39713481Sgiacomo.travaglini@arm.com 39813481Sgiacomo.travaglini@arm.com``` 39913481Sgiacomo.travaglini@arm.com// foo.Bar() should be called twice, return 1 the first time, and return 40013481Sgiacomo.travaglini@arm.com// 2 the second time. Using a sequence, we can write the expectations 40113481Sgiacomo.travaglini@arm.com// in their natural order. 40213481Sgiacomo.travaglini@arm.com{ 40313481Sgiacomo.travaglini@arm.com InSequence s; 40413481Sgiacomo.travaglini@arm.com EXPECT_CALL(foo, Bar()) 40513481Sgiacomo.travaglini@arm.com .WillOnce(Return(1)) 40613481Sgiacomo.travaglini@arm.com .RetiresOnSaturation(); 40713481Sgiacomo.travaglini@arm.com EXPECT_CALL(foo, Bar()) 40813481Sgiacomo.travaglini@arm.com .WillOnce(Return(2)) 40913481Sgiacomo.travaglini@arm.com .RetiresOnSaturation(); 41013481Sgiacomo.travaglini@arm.com} 41113481Sgiacomo.travaglini@arm.com``` 41213481Sgiacomo.travaglini@arm.com 41313481Sgiacomo.travaglini@arm.comor you can put the sequence of actions in the same expectation: 41413481Sgiacomo.travaglini@arm.com 41513481Sgiacomo.travaglini@arm.com``` 41613481Sgiacomo.travaglini@arm.com// foo.Bar() should be called twice, return 1 the first time, and return 41713481Sgiacomo.travaglini@arm.com// 2 the second time. 41813481Sgiacomo.travaglini@arm.comEXPECT_CALL(foo, Bar()) 41913481Sgiacomo.travaglini@arm.com .WillOnce(Return(1)) 42013481Sgiacomo.travaglini@arm.com .WillOnce(Return(2)) 42113481Sgiacomo.travaglini@arm.com .RetiresOnSaturation(); 42213481Sgiacomo.travaglini@arm.com``` 42313481Sgiacomo.travaglini@arm.com 42413481Sgiacomo.travaglini@arm.comBack to the original questions: why does Google Mock search the 42513481Sgiacomo.travaglini@arm.comexpectations (and `ON_CALL`s) from back to front? Because this 42613481Sgiacomo.travaglini@arm.comallows a user to set up a mock's behavior for the common case early 42713481Sgiacomo.travaglini@arm.com(e.g. in the mock's constructor or the test fixture's set-up phase) 42813481Sgiacomo.travaglini@arm.comand customize it with more specific rules later. If Google Mock 42913481Sgiacomo.travaglini@arm.comsearches from front to back, this very useful pattern won't be 43013481Sgiacomo.travaglini@arm.compossible. 43113481Sgiacomo.travaglini@arm.com 43213481Sgiacomo.travaglini@arm.com## Google Mock prints a warning when a function without EXPECT\_CALL is called, even if I have set its behavior using ON\_CALL. Would it be reasonable not to show the warning in this case? ## 43313481Sgiacomo.travaglini@arm.com 43413481Sgiacomo.travaglini@arm.comWhen choosing between being neat and being safe, we lean toward the 43513481Sgiacomo.travaglini@arm.comlatter. So the answer is that we think it's better to show the 43613481Sgiacomo.travaglini@arm.comwarning. 43713481Sgiacomo.travaglini@arm.com 43813481Sgiacomo.travaglini@arm.comOften people write `ON_CALL`s in the mock object's 43913481Sgiacomo.travaglini@arm.comconstructor or `SetUp()`, as the default behavior rarely changes from 44013481Sgiacomo.travaglini@arm.comtest to test. Then in the test body they set the expectations, which 44113481Sgiacomo.travaglini@arm.comare often different for each test. Having an `ON_CALL` in the set-up 44213481Sgiacomo.travaglini@arm.compart of a test doesn't mean that the calls are expected. If there's 44313481Sgiacomo.travaglini@arm.comno `EXPECT_CALL` and the method is called, it's possibly an error. If 44413481Sgiacomo.travaglini@arm.comwe quietly let the call go through without notifying the user, bugs 44513481Sgiacomo.travaglini@arm.commay creep in unnoticed. 44613481Sgiacomo.travaglini@arm.com 44713481Sgiacomo.travaglini@arm.comIf, however, you are sure that the calls are OK, you can write 44813481Sgiacomo.travaglini@arm.com 44913481Sgiacomo.travaglini@arm.com``` 45013481Sgiacomo.travaglini@arm.comEXPECT_CALL(foo, Bar(_)) 45113481Sgiacomo.travaglini@arm.com .WillRepeatedly(...); 45213481Sgiacomo.travaglini@arm.com``` 45313481Sgiacomo.travaglini@arm.com 45413481Sgiacomo.travaglini@arm.cominstead of 45513481Sgiacomo.travaglini@arm.com 45613481Sgiacomo.travaglini@arm.com``` 45713481Sgiacomo.travaglini@arm.comON_CALL(foo, Bar(_)) 45813481Sgiacomo.travaglini@arm.com .WillByDefault(...); 45913481Sgiacomo.travaglini@arm.com``` 46013481Sgiacomo.travaglini@arm.com 46113481Sgiacomo.travaglini@arm.comThis tells Google Mock that you do expect the calls and no warning should be 46213481Sgiacomo.travaglini@arm.comprinted. 46313481Sgiacomo.travaglini@arm.com 46413481Sgiacomo.travaglini@arm.comAlso, you can control the verbosity using the `--gmock_verbose` flag. 46513481Sgiacomo.travaglini@arm.comIf you find the output too noisy when debugging, just choose a less 46613481Sgiacomo.travaglini@arm.comverbose level. 46713481Sgiacomo.travaglini@arm.com 46813481Sgiacomo.travaglini@arm.com## How can I delete the mock function's argument in an action? ## 46913481Sgiacomo.travaglini@arm.com 47013481Sgiacomo.travaglini@arm.comIf you find yourself needing to perform some action that's not 47113481Sgiacomo.travaglini@arm.comsupported by Google Mock directly, remember that you can define your own 47213481Sgiacomo.travaglini@arm.comactions using 47313481Sgiacomo.travaglini@arm.com[MakeAction()](V1_5_CookBook#Writing_New_Actions.md) or 47413481Sgiacomo.travaglini@arm.com[MakePolymorphicAction()](V1_5_CookBook#Writing_New_Polymorphic_Actions.md), 47513481Sgiacomo.travaglini@arm.comor you can write a stub function and invoke it using 47613481Sgiacomo.travaglini@arm.com[Invoke()](V1_5_CookBook#Using_Functions_Methods_Functors.md). 47713481Sgiacomo.travaglini@arm.com 47813481Sgiacomo.travaglini@arm.com## MOCK\_METHODn()'s second argument looks funny. Why don't you use the MOCK\_METHODn(Method, return\_type, arg\_1, ..., arg\_n) syntax? ## 47913481Sgiacomo.travaglini@arm.com 48013481Sgiacomo.travaglini@arm.comWhat?! I think it's beautiful. :-) 48113481Sgiacomo.travaglini@arm.com 48213481Sgiacomo.travaglini@arm.comWhile which syntax looks more natural is a subjective matter to some 48313481Sgiacomo.travaglini@arm.comextent, Google Mock's syntax was chosen for several practical advantages it 48413481Sgiacomo.travaglini@arm.comhas. 48513481Sgiacomo.travaglini@arm.com 48613481Sgiacomo.travaglini@arm.comTry to mock a function that takes a map as an argument: 48713481Sgiacomo.travaglini@arm.com``` 48813481Sgiacomo.travaglini@arm.comvirtual int GetSize(const map<int, std::string>& m); 48913481Sgiacomo.travaglini@arm.com``` 49013481Sgiacomo.travaglini@arm.com 49113481Sgiacomo.travaglini@arm.comUsing the proposed syntax, it would be: 49213481Sgiacomo.travaglini@arm.com``` 49313481Sgiacomo.travaglini@arm.comMOCK_METHOD1(GetSize, int, const map<int, std::string>& m); 49413481Sgiacomo.travaglini@arm.com``` 49513481Sgiacomo.travaglini@arm.com 49613481Sgiacomo.travaglini@arm.comGuess what? You'll get a compiler error as the compiler thinks that 49713481Sgiacomo.travaglini@arm.com`const map<int, std::string>& m` are **two**, not one, arguments. To work 49813481Sgiacomo.travaglini@arm.comaround this you can use `typedef` to give the map type a name, but 49913481Sgiacomo.travaglini@arm.comthat gets in the way of your work. Google Mock's syntax avoids this 50013481Sgiacomo.travaglini@arm.comproblem as the function's argument types are protected inside a pair 50113481Sgiacomo.travaglini@arm.comof parentheses: 50213481Sgiacomo.travaglini@arm.com``` 50313481Sgiacomo.travaglini@arm.com// This compiles fine. 50413481Sgiacomo.travaglini@arm.comMOCK_METHOD1(GetSize, int(const map<int, std::string>& m)); 50513481Sgiacomo.travaglini@arm.com``` 50613481Sgiacomo.travaglini@arm.com 50713481Sgiacomo.travaglini@arm.comYou still need a `typedef` if the return type contains an unprotected 50813481Sgiacomo.travaglini@arm.comcomma, but that's much rarer. 50913481Sgiacomo.travaglini@arm.com 51013481Sgiacomo.travaglini@arm.comOther advantages include: 51113481Sgiacomo.travaglini@arm.com 1. `MOCK_METHOD1(Foo, int, bool)` can leave a reader wonder whether the method returns `int` or `bool`, while there won't be such confusion using Google Mock's syntax. 51213481Sgiacomo.travaglini@arm.com 1. The way Google Mock describes a function type is nothing new, although many people may not be familiar with it. The same syntax was used in C, and the `function` library in `tr1` uses this syntax extensively. Since `tr1` will become a part of the new version of STL, we feel very comfortable to be consistent with it. 51313481Sgiacomo.travaglini@arm.com 1. The function type syntax is also used in other parts of Google Mock's API (e.g. the action interface) in order to make the implementation tractable. A user needs to learn it anyway in order to utilize Google Mock's more advanced features. We'd as well stick to the same syntax in `MOCK_METHOD*`! 51413481Sgiacomo.travaglini@arm.com 51513481Sgiacomo.travaglini@arm.com## My code calls a static/global function. Can I mock it? ## 51613481Sgiacomo.travaglini@arm.com 51713481Sgiacomo.travaglini@arm.comYou can, but you need to make some changes. 51813481Sgiacomo.travaglini@arm.com 51913481Sgiacomo.travaglini@arm.comIn general, if you find yourself needing to mock a static function, 52013481Sgiacomo.travaglini@arm.comit's a sign that your modules are too tightly coupled (and less 52113481Sgiacomo.travaglini@arm.comflexible, less reusable, less testable, etc). You are probably better 52213481Sgiacomo.travaglini@arm.comoff defining a small interface and call the function through that 52313481Sgiacomo.travaglini@arm.cominterface, which then can be easily mocked. It's a bit of work 52413481Sgiacomo.travaglini@arm.cominitially, but usually pays for itself quickly. 52513481Sgiacomo.travaglini@arm.com 52613481Sgiacomo.travaglini@arm.comThis Google Testing Blog 52713481Sgiacomo.travaglini@arm.com[post](http://googletesting.blogspot.com/2008/06/defeat-static-cling.html) 52813481Sgiacomo.travaglini@arm.comsays it excellently. Check it out. 52913481Sgiacomo.travaglini@arm.com 53013481Sgiacomo.travaglini@arm.com## My mock object needs to do complex stuff. It's a lot of pain to specify the actions. Google Mock sucks! ## 53113481Sgiacomo.travaglini@arm.com 53213481Sgiacomo.travaglini@arm.comI know it's not a question, but you get an answer for free any way. :-) 53313481Sgiacomo.travaglini@arm.com 53413481Sgiacomo.travaglini@arm.comWith Google Mock, you can create mocks in C++ easily. And people might be 53513481Sgiacomo.travaglini@arm.comtempted to use them everywhere. Sometimes they work great, and 53613481Sgiacomo.travaglini@arm.comsometimes you may find them, well, a pain to use. So, what's wrong in 53713481Sgiacomo.travaglini@arm.comthe latter case? 53813481Sgiacomo.travaglini@arm.com 53913481Sgiacomo.travaglini@arm.comWhen you write a test without using mocks, you exercise the code and 54013481Sgiacomo.travaglini@arm.comassert that it returns the correct value or that the system is in an 54113481Sgiacomo.travaglini@arm.comexpected state. This is sometimes called "state-based testing". 54213481Sgiacomo.travaglini@arm.com 54313481Sgiacomo.travaglini@arm.comMocks are great for what some call "interaction-based" testing: 54413481Sgiacomo.travaglini@arm.cominstead of checking the system state at the very end, mock objects 54513481Sgiacomo.travaglini@arm.comverify that they are invoked the right way and report an error as soon 54613481Sgiacomo.travaglini@arm.comas it arises, giving you a handle on the precise context in which the 54713481Sgiacomo.travaglini@arm.comerror was triggered. This is often more effective and economical to 54813481Sgiacomo.travaglini@arm.comdo than state-based testing. 54913481Sgiacomo.travaglini@arm.com 55013481Sgiacomo.travaglini@arm.comIf you are doing state-based testing and using a test double just to 55113481Sgiacomo.travaglini@arm.comsimulate the real object, you are probably better off using a fake. 55213481Sgiacomo.travaglini@arm.comUsing a mock in this case causes pain, as it's not a strong point for 55313481Sgiacomo.travaglini@arm.commocks to perform complex actions. If you experience this and think 55413481Sgiacomo.travaglini@arm.comthat mocks suck, you are just not using the right tool for your 55513481Sgiacomo.travaglini@arm.comproblem. Or, you might be trying to solve the wrong problem. :-) 55613481Sgiacomo.travaglini@arm.com 55713481Sgiacomo.travaglini@arm.com## I got a warning "Uninteresting function call encountered - default action taken.." Should I panic? ## 55813481Sgiacomo.travaglini@arm.com 55913481Sgiacomo.travaglini@arm.comBy all means, NO! It's just an FYI. 56013481Sgiacomo.travaglini@arm.com 56113481Sgiacomo.travaglini@arm.comWhat it means is that you have a mock function, you haven't set any 56213481Sgiacomo.travaglini@arm.comexpectations on it (by Google Mock's rule this means that you are not 56313481Sgiacomo.travaglini@arm.cominterested in calls to this function and therefore it can be called 56413481Sgiacomo.travaglini@arm.comany number of times), and it is called. That's OK - you didn't say 56513481Sgiacomo.travaglini@arm.comit's not OK to call the function! 56613481Sgiacomo.travaglini@arm.com 56713481Sgiacomo.travaglini@arm.comWhat if you actually meant to disallow this function to be called, but 56813481Sgiacomo.travaglini@arm.comforgot to write `EXPECT_CALL(foo, Bar()).Times(0)`? While 56913481Sgiacomo.travaglini@arm.comone can argue that it's the user's fault, Google Mock tries to be nice and 57013481Sgiacomo.travaglini@arm.comprints you a note. 57113481Sgiacomo.travaglini@arm.com 57213481Sgiacomo.travaglini@arm.comSo, when you see the message and believe that there shouldn't be any 57313481Sgiacomo.travaglini@arm.comuninteresting calls, you should investigate what's going on. To make 57413481Sgiacomo.travaglini@arm.comyour life easier, Google Mock prints the function name and arguments 57513481Sgiacomo.travaglini@arm.comwhen an uninteresting call is encountered. 57613481Sgiacomo.travaglini@arm.com 57713481Sgiacomo.travaglini@arm.com## I want to define a custom action. Should I use Invoke() or implement the action interface? ## 57813481Sgiacomo.travaglini@arm.com 57913481Sgiacomo.travaglini@arm.comEither way is fine - you want to choose the one that's more convenient 58013481Sgiacomo.travaglini@arm.comfor your circumstance. 58113481Sgiacomo.travaglini@arm.com 58213481Sgiacomo.travaglini@arm.comUsually, if your action is for a particular function type, defining it 58313481Sgiacomo.travaglini@arm.comusing `Invoke()` should be easier; if your action can be used in 58413481Sgiacomo.travaglini@arm.comfunctions of different types (e.g. if you are defining 58513481Sgiacomo.travaglini@arm.com`Return(value)`), `MakePolymorphicAction()` is 58613481Sgiacomo.travaglini@arm.comeasiest. Sometimes you want precise control on what types of 58713481Sgiacomo.travaglini@arm.comfunctions the action can be used in, and implementing 58813481Sgiacomo.travaglini@arm.com`ActionInterface` is the way to go here. See the implementation of 58913481Sgiacomo.travaglini@arm.com`Return()` in `include/gmock/gmock-actions.h` for an example. 59013481Sgiacomo.travaglini@arm.com 59113481Sgiacomo.travaglini@arm.com## I'm using the set-argument-pointee action, and the compiler complains about "conflicting return type specified". What does it mean? ## 59213481Sgiacomo.travaglini@arm.com 59313481Sgiacomo.travaglini@arm.comYou got this error as Google Mock has no idea what value it should return 59413481Sgiacomo.travaglini@arm.comwhen the mock method is called. `SetArgumentPointee()` says what the 59513481Sgiacomo.travaglini@arm.comside effect is, but doesn't say what the return value should be. You 59613481Sgiacomo.travaglini@arm.comneed `DoAll()` to chain a `SetArgumentPointee()` with a `Return()`. 59713481Sgiacomo.travaglini@arm.com 59813481Sgiacomo.travaglini@arm.comSee this [recipe](V1_5_CookBook#Mocking_Side_Effects.md) for more details and an example. 59913481Sgiacomo.travaglini@arm.com 60013481Sgiacomo.travaglini@arm.com 60113481Sgiacomo.travaglini@arm.com## My question is not in your FAQ! ## 60213481Sgiacomo.travaglini@arm.com 60313481Sgiacomo.travaglini@arm.comIf you cannot find the answer to your question in this FAQ, there are 60413481Sgiacomo.travaglini@arm.comsome other resources you can use: 60513481Sgiacomo.travaglini@arm.com 60613481Sgiacomo.travaglini@arm.com 1. read other [wiki pages](http://code.google.com/p/googlemock/w/list), 60713481Sgiacomo.travaglini@arm.com 1. search the mailing list [archive](http://groups.google.com/group/googlemock/topics), 60813481Sgiacomo.travaglini@arm.com 1. ask it on [googlemock@googlegroups.com](mailto:googlemock@googlegroups.com) and someone will answer it (to prevent spam, we require you to join the [discussion group](http://groups.google.com/group/googlemock) before you can post.). 60913481Sgiacomo.travaglini@arm.com 61013481Sgiacomo.travaglini@arm.comPlease note that creating an issue in the 61113481Sgiacomo.travaglini@arm.com[issue tracker](http://code.google.com/p/googlemock/issues/list) is _not_ 61213481Sgiacomo.travaglini@arm.coma good way to get your answer, as it is monitored infrequently by a 61313481Sgiacomo.travaglini@arm.comvery small number of people. 61413481Sgiacomo.travaglini@arm.com 61513481Sgiacomo.travaglini@arm.comWhen asking a question, it's helpful to provide as much of the 61613481Sgiacomo.travaglini@arm.comfollowing information as possible (people cannot help you if there's 61713481Sgiacomo.travaglini@arm.comnot enough information in your question): 61813481Sgiacomo.travaglini@arm.com 61913481Sgiacomo.travaglini@arm.com * the version (or the revision number if you check out from SVN directly) of Google Mock you use (Google Mock is under active development, so it's possible that your problem has been solved in a later version), 62013481Sgiacomo.travaglini@arm.com * your operating system, 62113481Sgiacomo.travaglini@arm.com * the name and version of your compiler, 62213481Sgiacomo.travaglini@arm.com * the complete command line flags you give to your compiler, 62313481Sgiacomo.travaglini@arm.com * the complete compiler error messages (if the question is about compilation), 62413481Sgiacomo.travaglini@arm.com * the _actual_ code (ideally, a minimal but complete program) that has the problem you encounter.