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