gMock Cookbook

You can find recipes for using gMock here. If you haven’t yet, please read
the dummy guide first to make sure you understand the
basics.

{: .callout .note}
Note: gMock lives in the testing name space. For readability, it is
recommended to write using ::testing::Foo; once in your file before using the
name Foo defined by gMock. We omit such using statements in this section for
brevity, but you should do it in your own code.

Creating Mock Classes

Mock classes are defined as normal classes, using the MOCK_METHOD macro to
generate mocked methods. The macro gets 3 or 4 parameters:

class MyMock {
 public:
  MOCK_METHOD(ReturnType, MethodName, (Args...));
  MOCK_METHOD(ReturnType, MethodName, (Args...), (Specs...));
};

The first 3 parameters are simply the method declaration, split into 3 parts.
The 4th parameter accepts a closed list of qualifiers, which affect the
generated method:

• const - Makes the mocked method a const method. Required if
  overriding a const method.
• override - Marks the method with override. Recommended if overriding
  a virtual method.
• noexcept - Marks the method with noexcept. Required if overriding a
  noexcept method.
• Calltype(...) - Sets the call type for the method (e.g. to
  STDMETHODCALLTYPE), useful in Windows.
• ref(...) - Marks the method with the reference qualification
  specified. Required if overriding a method that has reference
  qualifications. Eg ref(&) or ref(&&).

Dealing with unprotected commas

Unprotected commas, i.e. commas which are not surrounded by parentheses, prevent
MOCK_METHOD from parsing its arguments correctly:

{: .bad}

class MockFoo {
 public:
  MOCK_METHOD(std::pair<bool, int>, GetPair, ());  // Won't compile!
  MOCK_METHOD(bool, CheckMap, (std::map<int, double>, bool));  // Won't compile!
};

Solution 1 - wrap with parentheses:

{: .good}

class MockFoo {
 public:
  MOCK_METHOD((std::pair<bool, int>), GetPair, ());
  MOCK_METHOD(bool, CheckMap, ((std::map<int, double>), bool));
};

Note that wrapping a return or argument type with parentheses is, in general,
invalid C++. MOCK_METHOD removes the parentheses.

Solution 2 - define an alias:

{: .good}

class MockFoo {
 public:
  using BoolAndInt = std::pair<bool, int>;
  MOCK_METHOD(BoolAndInt, GetPair, ());
  using MapIntDouble = std::map<int, double>;
  MOCK_METHOD(bool, CheckMap, (MapIntDouble, bool));
};

Mocking Private or Protected Methods

You must always put a mock method definition (MOCK_METHOD) in a public:
section of the mock class, regardless of the method being mocked being public,
protected, or private in the base class. This allows ON_CALL and
EXPECT_CALL to reference the mock function from outside of the mock class.
(Yes, C++ allows a subclass to change the access level of a virtual function in
the base class.) Example:

class Foo {
 public:
  ...
  virtual bool Transform(Gadget* g) = 0;
 protected:
  virtual void Resume();
 private:
  virtual int GetTimeOut();
};
class MockFoo : public Foo {
 public:
  ...
  MOCK_METHOD(bool, Transform, (Gadget* g), (override));
  // The following must be in the public section, even though the
  // methods are protected or private in the base class.
  MOCK_METHOD(void, Resume, (), (override));
  MOCK_METHOD(int, GetTimeOut, (), (override));
};

Mocking Overloaded Methods

You can mock overloaded functions as usual. No special attention is required:

class Foo {
  ...
  // Must be virtual as we'll inherit from Foo.
  virtual ~Foo();
  // Overloaded on the types and/or numbers of arguments.
  virtual int Add(Element x);
  virtual int Add(int times, Element x);
  // Overloaded on the const-ness of this object.
  virtual Bar& GetBar();
  virtual const Bar& GetBar() const;
};
class MockFoo : public Foo {
  ...
  MOCK_METHOD(int, Add, (Element x), (override));
  MOCK_METHOD(int, Add, (int times, Element x), (override));
  MOCK_METHOD(Bar&, GetBar, (), (override));
  MOCK_METHOD(const Bar&, GetBar, (), (const, override));
};

{: .callout .note}
Note: if you don’t mock all versions of the overloaded method, the compiler
will give you a warning about some methods in the base class being hidden. To
fix that, use using to bring them in scope:

class MockFoo : public Foo {
  ...
  using Foo::Add;
  MOCK_METHOD(int, Add, (Element x), (override));
  // We don't want to mock int Add(int times, Element x);
  ...
};

Mocking Class Templates

You can mock class templates just like any class.

template <typename Elem>
class StackInterface {
  ...
  // Must be virtual as we'll inherit from StackInterface.
  virtual ~StackInterface();
  virtual int GetSize() const = 0;
  virtual void Push(const Elem& x) = 0;
};
template <typename Elem>
class MockStack : public StackInterface<Elem> {
  ...
  MOCK_METHOD(int, GetSize, (), (override));
  MOCK_METHOD(void, Push, (const Elem& x), (override));
};

Mocking Non-virtual Methods {#MockingNonVirtualMethods}

gMock can mock non-virtual functions to be used in Hi-perf dependency injection.

In this case, instead of sharing a common base class with the real class, your
mock class will be unrelated to the real class, but contain methods with the
same signatures. The syntax for mocking non-virtual methods is the same as
mocking virtual methods (just don’t add override):

// A simple packet stream class.  None of its members is virtual.
class ConcretePacketStream {
 public:
  void AppendPacket(Packet* new_packet);
  const Packet* GetPacket(size_t packet_number) const;
  size_t NumberOfPackets() const;
  ...
};
// A mock packet stream class.  It inherits from no other, but defines
// GetPacket() and NumberOfPackets().
class MockPacketStream {
 public:
  MOCK_METHOD(const Packet*, GetPacket, (size_t packet_number), (const));
  MOCK_METHOD(size_t, NumberOfPackets, (), (const));
  ...
};

Note that the mock class doesn’t define AppendPacket(), unlike the real class.
That’s fine as long as the test doesn’t need to call it.

Next, you need a way to say that you want to use ConcretePacketStream in
production code, and use MockPacketStream in tests. Since the functions are
not virtual and the two classes are unrelated, you must specify your choice at
compile time (as opposed to run time).

One way to do it is to templatize your code that needs to use a packet stream.
More specifically, you will give your code a template type argument for the type
of the packet stream. In production, you will instantiate your template with
ConcretePacketStream as the type argument. In tests, you will instantiate the
same template with MockPacketStream. For example, you may write:

template <class PacketStream>
void CreateConnection(PacketStream* stream) { ... }
template <class PacketStream>
class PacketReader {
 public:
  void ReadPackets(PacketStream* stream, size_t packet_num);
};

Then you can use CreateConnection<ConcretePacketStream>() and
PacketReader<ConcretePacketStream> in production code, and use
CreateConnection<MockPacketStream>() and PacketReader<MockPacketStream> in
tests.

  MockPacketStream mock_stream;
  EXPECT_CALL(mock_stream, ...)...;
  .. set more expectations on mock_stream ...
  PacketReader<MockPacketStream> reader(&mock_stream);
  ... exercise reader ...

Mocking Free Functions

It is not possible to directly mock a free function (i.e. a C-style function or
a static method). If you need to, you can rewrite your code to use an interface
(abstract class).

Instead of calling a free function (say, OpenFile) directly, introduce an
interface for it and have a concrete subclass that calls the free function:

class FileInterface {
 public:
  ...
  virtual bool Open(const char* path, const char* mode) = 0;
};
class File : public FileInterface {
 public:
  ...
  bool Open(const char* path, const char* mode) override {
     return OpenFile(path, mode);
  }
};

Your code should talk to FileInterface to open a file. Now it’s easy to mock
out the function.

This may seem like a lot of hassle, but in practice you often have multiple
related functions that you can put in the same interface, so the per-function
syntactic overhead will be much lower.

If you are concerned about the performance overhead incurred by virtual
functions, and profiling confirms your concern, you can combine this with the
recipe for mocking non-virtual methods.

Old-Style MOCK_METHODn Macros

Before the generic MOCK_METHOD macro
was introduced in 2018,
mocks where created using a family of macros collectively called MOCK_METHODn.
These macros are still supported, though migration to the new MOCK_METHOD is
recommended.

The macros in the MOCK_METHODn family differ from MOCK_METHOD:

• The general structure is MOCK_METHODn(MethodName, ReturnType(Args)),
  instead of MOCK_METHOD(ReturnType, MethodName, (Args)).
• The number n must equal the number of arguments.
• When mocking a const method, one must use MOCK_CONST_METHODn.
• When mocking a class template, the macro name must be suffixed with _T.
• In order to specify the call type, the macro name must be suffixed with
  _WITH_CALLTYPE, and the call type is the first macro argument.

Old macros and their new equivalents:

The Nice, the Strict, and the Naggy {#NiceStrictNaggy}

If a mock method has no EXPECT_CALL spec but is called, we say that it’s an
“uninteresting call”, and the default action (which can be specified using
ON_CALL()) of the method will be taken. Currently, an uninteresting call will
also by default cause gMock to print a warning. (In the future, we might remove
this warning by default.)

However, sometimes you may want to ignore these uninteresting calls, and
sometimes you may want to treat them as errors. gMock lets you make the decision
on a per-mock-object basis.

Suppose your test uses a mock class MockFoo:

TEST(...) {
  MockFoo mock_foo;
  EXPECT_CALL(mock_foo, DoThis());
  ... code that uses mock_foo ...
}

If a method of mock_foo other than DoThis() is called, you will get a
warning. However, if you rewrite your test to use NiceMock<MockFoo> instead,
you can suppress the warning:

using ::testing::NiceMock;
TEST(...) {
  NiceMock<MockFoo> mock_foo;
  EXPECT_CALL(mock_foo, DoThis());
  ... code that uses mock_foo ...
}

NiceMock<MockFoo> is a subclass of MockFoo, so it can be used wherever
MockFoo is accepted.

It also works if MockFoo‘s constructor takes some arguments, as
NiceMock<MockFoo> “inherits” MockFoo‘s constructors:

using ::testing::NiceMock;
TEST(...) {
  NiceMock<MockFoo> mock_foo(5, "hi");  // Calls MockFoo(5, "hi").
  EXPECT_CALL(mock_foo, DoThis());
  ... code that uses mock_foo ...
}

The usage of StrictMock is similar, except that it makes all uninteresting
calls failures:

using ::testing::StrictMock;
TEST(...) {
  StrictMock<MockFoo> mock_foo;
  EXPECT_CALL(mock_foo, DoThis());
  ... code that uses mock_foo ...
  // The test will fail if a method of mock_foo other than DoThis()
  // is called.
}

{: .callout .note}
NOTE: NiceMock and StrictMock only affects uninteresting calls (calls of
methods with no expectations); they do not affect unexpected calls (calls of
methods with expectations, but they don’t match). See
Understanding Uninteresting vs Unexpected Calls.

There are some caveats though (sadly they are side effects of C++’s
limitations):

1. NiceMock<MockFoo> and StrictMock<MockFoo> only work for mock methods
   defined using the MOCK_METHOD macro directly in the MockFoo class.
   If a mock method is defined in a base class of MockFoo, the “nice” or
   “strict” modifier may not affect it, depending on the compiler. In
   particular, nesting NiceMock and StrictMock (e.g.
   NiceMock<StrictMock<MockFoo> >) is not supported.
2. NiceMock<MockFoo> and StrictMock<MockFoo> may not work correctly if the
   destructor of MockFoo is not virtual. We would like to fix this, but it
   requires cleaning up existing tests.

Finally, you should be very cautious about when to use naggy or strict
mocks, as they tend to make tests more brittle and harder to maintain. When you
refactor your code without changing its externally visible behavior, ideally you
shouldn’t need to update any tests. If your code interacts with a naggy mock,
however, you may start to get spammed with warnings as the result of your
change. Worse, if your code interacts with a strict mock, your tests may start
to fail and you’ll be forced to fix them. Our general recommendation is to use
nice mocks (not yet the default) most of the time, use naggy mocks (the current
default) when developing or debugging tests, and use strict mocks only as the
last resort.

Simplifying the Interface without Breaking Existing Code {#SimplerInterfaces}

Sometimes a method has a long list of arguments that is mostly uninteresting.
For example:

class LogSink {
 public:
  ...
  virtual void send(LogSeverity severity, const char* full_filename,
                    const char* base_filename, int line,
                    const struct tm* tm_time,
                    const char* message, size_t message_len) = 0;
};

This method’s argument list is lengthy and hard to work with (the message
argument is not even 0-terminated). If we mock it as is, using the mock will be
awkward. If, however, we try to simplify this interface, we’ll need to fix all
clients depending on it, which is often infeasible.

The trick is to redispatch the method in the mock class:

class ScopedMockLog : public LogSink {
 public:
  ...
  void send(LogSeverity severity, const char* full_filename,
                    const char* base_filename, int line, const tm* tm_time,
                    const char* message, size_t message_len) override {
    // We are only interested in the log severity, full file name, and
    // log message.
    Log(severity, full_filename, std::string(message, message_len));
  }
  // Implements the mock method:
  //
  //   void Log(LogSeverity severity,
  //            const string& file_path,
  //            const string& message);
  MOCK_METHOD(void, Log,
              (LogSeverity severity, const string& file_path,
               const string& message));
};

By defining a new mock method with a trimmed argument list, we make the mock
class more user-friendly.

This technique may also be applied to make overloaded methods more amenable to
mocking. For example, when overloads have been used to implement default
arguments:

class MockTurtleFactory : public TurtleFactory {
 public:
  Turtle* MakeTurtle(int length, int weight) override { ... }
  Turtle* MakeTurtle(int length, int weight, int speed) override { ... }
  // the above methods delegate to this one:
  MOCK_METHOD(Turtle*, DoMakeTurtle, ());
};

This allows tests that don’t care which overload was invoked to avoid specifying
argument matchers:

ON_CALL(factory, DoMakeTurtle)
    .WillByDefault(Return(MakeMockTurtle()));

Alternative to Mocking Concrete Classes

Often you may find yourself using classes that don’t implement interfaces. In
order to test your code that uses such a class (let’s call it Concrete), you
may be tempted to make the methods of Concrete virtual and then mock it.

Try not to do that.

Making a non-virtual function virtual is a big decision. It creates an extension
point where subclasses can tweak your class’ behavior. This weakens your control
on the class because now it’s harder to maintain the class invariants. You
should make a function virtual only when there is a valid reason for a subclass
to override it.

Mocking concrete classes directly is problematic as it creates a tight coupling
between the class and the tests - any small change in the class may invalidate
your tests and make test maintenance a pain.

To avoid such problems, many programmers have been practicing “coding to
interfaces”: instead of talking to the Concrete class, your code would define
an interface and talk to it. Then you implement that interface as an adaptor on
top of Concrete. In tests, you can easily mock that interface to observe how
your code is doing.

This technique incurs some overhead:

• You pay the cost of virtual function calls (usually not a problem).
• There is more abstraction for the programmers to learn.

However, it can also bring significant benefits in addition to better
testability:

• Concrete‘s API may not fit your problem domain very well, as you may not
  be the only client it tries to serve. By designing your own interface, you
  have a chance to tailor it to your need - you may add higher-level
  functionalities, rename stuff, etc instead of just trimming the class. This
  allows you to write your code (user of the interface) in a more natural way,
  which means it will be more readable, more maintainable, and you’ll be more
  productive.
• If Concrete‘s implementation ever has to change, you don’t have to rewrite
  everywhere it is used. Instead, you can absorb the change in your
  implementation of the interface, and your other code and tests will be
  insulated from this change.

Some people worry that if everyone is practicing this technique, they will end
up writing lots of redundant code. This concern is totally understandable.
However, there are two reasons why it may not be the case:

• Different projects may need to use Concrete in different ways, so the best
  interfaces for them will be different. Therefore, each of them will have its
  own domain-specific interface on top of Concrete, and they will not be the
  same code.
• If enough projects want to use the same interface, they can always share it,
  just like they have been sharing Concrete. You can check in the interface
  and the adaptor somewhere near Concrete (perhaps in a contrib
  sub-directory) and let many projects use it.

You need to weigh the pros and cons carefully for your particular problem, but
I’d like to assure you that the Java community has been practicing this for a
long time and it’s a proven effective technique applicable in a wide variety of
situations. :-)

Delegating Calls to a Fake {#DelegatingToFake}

Some times you have a non-trivial fake implementation of an interface. For
example:

class Foo {
 public:
  virtual ~Foo() {}
  virtual char DoThis(int n) = 0;
  virtual void DoThat(const char* s, int* p) = 0;
};
class FakeFoo : public Foo {
 public:
  char DoThis(int n) override {
    return (n > 0) ? '+' :
           (n < 0) ? '-' : '0';
  }
  void DoThat(const char* s, int* p) override {
    *p = strlen(s);
  }
};

Now you want to mock this interface such that you can set expectations on it.
However, you also want to use FakeFoo for the default behavior, as duplicating
it in the mock object is, well, a lot of work.

When you define the mock class using gMock, you can have it delegate its default
action to a fake class you already have, using this pattern:

class MockFoo : public Foo {
 public:
  // Normal mock method definitions using gMock.
  MOCK_METHOD(char, DoThis, (int n), (override));
  MOCK_METHOD(void, DoThat, (const char* s, int* p), (override));
  // Delegates the default actions of the methods to a FakeFoo object.
  // This must be called *before* the custom ON_CALL() statements.
  void DelegateToFake() {
    ON_CALL(*this, DoThis).WillByDefault([this](int n) {
      return fake_.DoThis(n);
    });
    ON_CALL(*this, DoThat).WillByDefault([this](const char* s, int* p) {
      fake_.DoThat(s, p);
    });
  }
 private:
  FakeFoo fake_;  // Keeps an instance of the fake in the mock.
};

With that, you can use MockFoo in your tests as usual. Just remember that if
you don’t explicitly set an action in an ON_CALL() or EXPECT_CALL(), the
fake will be called upon to do it.:

using ::testing::_;
TEST(AbcTest, Xyz) {
  MockFoo foo;
  foo.DelegateToFake();  // Enables the fake for delegation.
  // Put your ON_CALL(foo, ...)s here, if any.
  // No action specified, meaning to use the default action.
  EXPECT_CALL(foo, DoThis(5));
  EXPECT_CALL(foo, DoThat(_, _));
  int n = 0;
  EXPECT_EQ('+', foo.DoThis(5));  // FakeFoo::DoThis() is invoked.
  foo.DoThat("Hi", &n);  // FakeFoo::DoThat() is invoked.
  EXPECT_EQ(2, n);
}

Some tips:

• If you want, you can still override the default action by providing your own
  ON_CALL() or using .WillOnce() / .WillRepeatedly() in EXPECT_CALL().

• In DelegateToFake(), you only need to delegate the methods whose fake
  implementation you intend to use.

• The general technique discussed here works for overloaded methods, but
  you’ll need to tell the compiler which version you mean. To disambiguate a
  mock function (the one you specify inside the parentheses of ON_CALL()),
  use this technique; to disambiguate a fake function (the
  one you place inside Invoke()), use a static_cast to specify the
  function’s type. For instance, if class Foo has methods char DoThis(int n) and bool DoThis(double x) const, and you want to invoke the latter,
  you need to write Invoke(&fake_, static_cast<bool (FakeFoo::*)(double) const>(&FakeFoo::DoThis)) instead of Invoke(&fake_, &FakeFoo::DoThis)
  (The strange-looking thing inside the angled brackets of static_cast is
  the type of a function pointer to the second DoThis() method.).

• Having to mix a mock and a fake is often a sign of something gone wrong.
  Perhaps you haven’t got used to the interaction-based way of testing yet. Or
  perhaps your interface is taking on too many roles and should be split up.
  Therefore, don’t abuse this. We would only recommend to do it as an
  intermediate step when you are refactoring your code.

Regarding the tip on mixing a mock and a fake, here’s an example on why it may
be a bad sign: Suppose you have a class System for low-level system
operations. In particular, it does file and I/O operations. And suppose you want
to test how your code uses System to do I/O, and you just want the file
operations to work normally. If you mock out the entire System class, you’ll
have to provide a fake implementation for the file operation part, which
suggests that System is taking on too many roles.

Instead, you can define a FileOps interface and an IOOps interface and split
System‘s functionalities into the two. Then you can mock IOOps without
mocking FileOps.

Delegating Calls to a Real Object

When using testing doubles (mocks, fakes, stubs, and etc), sometimes their
behaviors will differ from those of the real objects. This difference could be
either intentional (as in simulating an error such that you can test the error
handling code) or unintentional. If your mocks have different behaviors than the
real objects by mistake, you could end up with code that passes the tests but
fails in production.

You can use the delegating-to-real technique to ensure that your mock has the
same behavior as the real object while retaining the ability to validate calls.
This technique is very similar to the delegating-to-fake
technique, the difference being that we use a real object instead of a fake.
Here’s an example:

using ::testing::AtLeast;
class MockFoo : public Foo {
 public:
  MockFoo() {
    // By default, all calls are delegated to the real object.
    ON_CALL(*this, DoThis).WillByDefault([this](int n) {
      return real_.DoThis(n);
    });
    ON_CALL(*this, DoThat).WillByDefault([this](const char* s, int* p) {
      real_.DoThat(s, p);
    });
    ...
  }
  MOCK_METHOD(char, DoThis, ...);
  MOCK_METHOD(void, DoThat, ...);
  ...
 private:
  Foo real_;
};
...
  MockFoo mock;
  EXPECT_CALL(mock, DoThis())
      .Times(3);
  EXPECT_CALL(mock, DoThat("Hi"))
      .Times(AtLeast(1));
  ... use mock in test ...

With this, gMock will verify that your code made the right calls (with the right
arguments, in the right order, called the right number of times, etc), and a
real object will answer the calls (so the behavior will be the same as in
production). This gives you the best of both worlds.

Delegating Calls to a Parent Class

Ideally, you should code to interfaces, whose methods are all pure virtual. In
reality, sometimes you do need to mock a virtual method that is not pure (i.e,
it already has an implementation). For example:

class Foo {
 public:
  virtual ~Foo();
  virtual void Pure(int n) = 0;
  virtual int Concrete(const char* str) { ... }
};
class MockFoo : public Foo {
 public:
  // Mocking a pure method.
  MOCK_METHOD(void, Pure, (int n), (override));
  // Mocking a concrete method.  Foo::Concrete() is shadowed.
  MOCK_METHOD(int, Concrete, (const char* str), (override));
};

Sometimes you may want to call Foo::Concrete() instead of
MockFoo::Concrete(). Perhaps you want to do it as part of a stub action, or
perhaps your test doesn’t need to mock Concrete() at all (but it would be
oh-so painful to have to define a new mock class whenever you don’t need to mock
one of its methods).

You can call Foo::Concrete() inside an action by:

...
  EXPECT_CALL(foo, Concrete).WillOnce([&foo](const char* str) {
    return foo.Foo::Concrete(str);
  });

or tell the mock object that you don’t want to mock Concrete():

...
  ON_CALL(foo, Concrete).WillByDefault([&foo](const char* str) {
    return foo.Foo::Concrete(str);
  });

(Why don’t we just write { return foo.Concrete(str); }? If you do that,
MockFoo::Concrete() will be called (and cause an infinite recursion) since
Foo::Concrete() is virtual. That’s just how C++ works.)

Using Matchers

Matching Argument Values Exactly

You can specify exactly which arguments a mock method is expecting:

using ::testing::Return;
...
  EXPECT_CALL(foo, DoThis(5))
      .WillOnce(Return('a'));
  EXPECT_CALL(foo, DoThat("Hello", bar));

Using Simple Matchers

You can use matchers to match arguments that have a certain property:

using ::testing::NotNull;
using ::testing::Return;
...
  EXPECT_CALL(foo, DoThis(Ge(5)))  // The argument must be >= 5.
      .WillOnce(Return('a'));
  EXPECT_CALL(foo, DoThat("Hello", NotNull()));
      // The second argument must not be NULL.

A frequently used matcher is _, which matches anything:

  EXPECT_CALL(foo, DoThat(_, NotNull()));

Combining Matchers {#CombiningMatchers}

You can build complex matchers from existing ones using AllOf(),
AllOfArray(), AnyOf(), AnyOfArray() and Not():

using ::testing::AllOf;
using ::testing::Gt;
using ::testing::HasSubstr;
using ::testing::Ne;
using ::testing::Not;
...
  // The argument must be > 5 and != 10.
  EXPECT_CALL(foo, DoThis(AllOf(Gt(5),
                                Ne(10))));
  // The first argument must not contain sub-string "blah".
  EXPECT_CALL(foo, DoThat(Not(HasSubstr("blah")),
                          NULL));

Matchers are function objects, and parametrized matchers can be composed just
like any other function. However because their types can be long and rarely
provide meaningful information, it can be easier to express them with C++14
generic lambdas to avoid specifying types. For example,

using ::testing::Contains;
using ::testing::Property;
inline constexpr auto HasFoo = [](const auto& f) {
  return Property(&MyClass::foo, Contains(f));
};
...
  EXPECT_THAT(x, HasFoo("blah"));

Casting Matchers {#SafeMatcherCast}

gMock matchers are statically typed, meaning that the compiler can catch your
mistake if you use a matcher of the wrong type (for example, if you use Eq(5)
to match a string argument). Good for you!

Sometimes, however, you know what you’re doing and want the compiler to give you
some slack. One example is that you have a matcher for long and the argument
you want to match is int. While the two types aren’t exactly the same, there
is nothing really wrong with using a Matcher<long> to match an int - after
all, we can first convert the int argument to a long losslessly before
giving it to the matcher.

To support this need, gMock gives you the SafeMatcherCast<T>(m) function. It
casts a matcher m to type Matcher<T>. To ensure safety, gMock checks that
(let U be the type m accepts :

1. Type T can be implicitly cast to type U;
2. When both T and U are built-in arithmetic types (bool, integers, and
   floating-point numbers), the conversion from T to U is not lossy (in
   other words, any value representable by T can also be represented by U);
   and
3. When U is a reference, T must also be a reference (as the underlying
   matcher may be interested in the address of the U value).

The code won’t compile if any of these conditions isn’t met.

Here’s one example:

using ::testing::SafeMatcherCast;
// A base class and a child class.
class Base { ... };
class Derived : public Base { ... };
class MockFoo : public Foo {
 public:
  MOCK_METHOD(void, DoThis, (Derived* derived), (override));
};
...
  MockFoo foo;
  // m is a Matcher<Base*> we got from somewhere.
  EXPECT_CALL(foo, DoThis(SafeMatcherCast<Derived*>(m)));

If you find SafeMatcherCast<T>(m) too limiting, you can use a similar function
MatcherCast<T>(m). The difference is that MatcherCast works as long as you
can static_cast type T to type U.

MatcherCast essentially lets you bypass C++’s type system (static_cast isn’t
always safe as it could throw away information, for example), so be careful not
to misuse/abuse it.

Selecting Between Overloaded Functions {#SelectOverload}

If you expect an overloaded function to be called, the compiler may need some
help on which overloaded version it is.

To disambiguate functions overloaded on the const-ness of this object, use the
Const() argument wrapper.

using ::testing::ReturnRef;
class MockFoo : public Foo {
  ...
  MOCK_METHOD(Bar&, GetBar, (), (override));
  MOCK_METHOD(const Bar&, GetBar, (), (const, override));
};
...
  MockFoo foo;
  Bar bar1, bar2;
  EXPECT_CALL(foo, GetBar())         // The non-const GetBar().
      .WillOnce(ReturnRef(bar1));
  EXPECT_CALL(Const(foo), GetBar())  // The const GetBar().
      .WillOnce(ReturnRef(bar2));

(Const() is defined by gMock and returns a const reference to its argument.)

To disambiguate overloaded functions with the same number of arguments but
different argument types, you may need to specify the exact type of a matcher,
either by wrapping your matcher in Matcher<type>(), or using a matcher whose
type is fixed (TypedEq<type>, An<type>(), etc):

using ::testing::An;
using ::testing::Matcher;
using ::testing::TypedEq;
class MockPrinter : public Printer {
 public:
  MOCK_METHOD(void, Print, (int n), (override));
  MOCK_METHOD(void, Print, (char c), (override));
};
TEST(PrinterTest, Print) {
  MockPrinter printer;
  EXPECT_CALL(printer, Print(An<int>()));            // void Print(int);
  EXPECT_CALL(printer, Print(Matcher<int>(Lt(5))));  // void Print(int);
  EXPECT_CALL(printer, Print(TypedEq<char>('a')));   // void Print(char);
  printer.Print(3);
  printer.Print(6);
  printer.Print('a');
}

Performing Different Actions Based on the Arguments

When a mock method is called, the last matching expectation that’s still
active will be selected (think “newer overrides older”). So, you can make a
method do different things depending on its argument values like this:

using ::testing::_;
using ::testing::Lt;
using ::testing::Return;
...
  // The default case.
  EXPECT_CALL(foo, DoThis(_))
      .WillRepeatedly(Return('b'));
  // The more specific case.
  EXPECT_CALL(foo, DoThis(Lt(5)))
      .WillRepeatedly(Return('a'));

Now, if foo.DoThis() is called with a value less than 5, 'a' will be
returned; otherwise 'b' will be returned.

Matching Multiple Arguments as a Whole

Sometimes it’s not enough to match the arguments individually. For example, we
may want to say that the first argument must be less than the second argument.
The With() clause allows us to match all arguments of a mock function as a
whole. For example,

using ::testing::_;
using ::testing::Ne;
using ::testing::Lt;
...
  EXPECT_CALL(foo, InRange(Ne(0), _))
      .With(Lt());

says that the first argument of InRange() must not be 0, and must be less than
the second argument.

The expression inside With() must be a matcher of type Matcher<std::tuple<A1, ..., An>>, where A1, …, An are the types of the function arguments.

You can also write AllArgs(m) instead of m inside .With(). The two forms
are equivalent, but .With(AllArgs(Lt())) is more readable than .With(Lt()).

You can use Args<k1, ..., kn>(m) to match the n selected arguments (as a
tuple) against m. For example,

using ::testing::_;
using ::testing::AllOf;
using ::testing::Args;
using ::testing::Lt;
...
  EXPECT_CALL(foo, Blah)
      .With(AllOf(Args<0, 1>(Lt()), Args<1, 2>(Lt())));

says that Blah will be called with arguments x, y, and z where x < y < z. Note that in this example, it wasn’t necessary to specify the positional
matchers.

As a convenience and example, gMock provides some matchers for 2-tuples,
including the Lt() matcher above. See
Multi-argument Matchers for the
complete list.

Note that if you want to pass the arguments to a predicate of your own (e.g.
.With(Args<0, 1>(Truly(&MyPredicate)))), that predicate MUST be written to
take a std::tuple as its argument; gMock will pass the n selected arguments
as one single tuple to the predicate.

Using Matchers as Predicates

Have you noticed that a matcher is just a fancy predicate that also knows how to
describe itself? Many existing algorithms take predicates as arguments (e.g.
those defined in STL’s <algorithm> header), and it would be a shame if gMock
matchers were not allowed to participate.

Luckily, you can use a matcher where a unary predicate functor is expected by
wrapping it inside the Matches() function. For example,

#include <algorithm>
#include <vector>
using ::testing::Matches;
using ::testing::Ge;
vector<int> v;
...
// How many elements in v are >= 10?
const int count = count_if(v.begin(), v.end(), Matches(Ge(10)));

Since you can build complex matchers from simpler ones easily using gMock, this
gives you a way to conveniently construct composite predicates (doing the same
using STL’s <functional> header is just painful). For example, here’s a
predicate that’s satisfied by any number that is >= 0, <= 100, and != 50:

using testing::AllOf;
using testing::Ge;
using testing::Le;
using testing::Matches;
using testing::Ne;
...
Matches(AllOf(Ge(0), Le(100), Ne(50)))

Using Matchers in googletest Assertions

See EXPECT_THAT in the Assertions
Reference.

Using Predicates as Matchers

gMock provides a set of built-in matchers for matching arguments with expected
values—see the Matchers Reference for more information.
In case you find the built-in set lacking, you can use an arbitrary unary
predicate function or functor as a matcher - as long as the predicate accepts a
value of the type you want. You do this by wrapping the predicate inside the
Truly() function, for example:

using ::testing::Truly;
int IsEven(int n) { return (n % 2) == 0 ? 1 : 0; }
...
  // Bar() must be called with an even number.
  EXPECT_CALL(foo, Bar(Truly(IsEven)));

Note that the predicate function / functor doesn’t have to return bool. It
works as long as the return value can be used as the condition in in statement
if (condition) ....

Matching Arguments that Are Not Copyable

When you do an EXPECT_CALL(mock_obj, Foo(bar)), gMock saves away a copy of
bar. When Foo() is called later, gMock compares the argument to Foo() with
the saved copy of bar. This way, you don’t need to worry about bar being
modified or destroyed after the EXPECT_CALL() is executed. The same is true
when you use matchers like Eq(bar), Le(bar), and so on.

But what if bar cannot be copied (i.e. has no copy constructor)? You could
define your own matcher function or callback and use it with Truly(), as the
previous couple of recipes have shown. Or, you may be able to get away from it
if you can guarantee that bar won’t be changed after the EXPECT_CALL() is
executed. Just tell gMock that it should save a reference to bar, instead of a
copy of it. Here’s how:

using ::testing::Eq;
using ::testing::Lt;
...
  // Expects that Foo()'s argument == bar.
  EXPECT_CALL(mock_obj, Foo(Eq(std::ref(bar))));
  // Expects that Foo()'s argument < bar.
  EXPECT_CALL(mock_obj, Foo(Lt(std::ref(bar))));

Remember: if you do this, don’t change bar after the EXPECT_CALL(), or the
result is undefined.

Validating a Member of an Object

Often a mock function takes a reference to object as an argument. When matching
the argument, you may not want to compare the entire object against a fixed
object, as that may be over-specification. Instead, you may need to validate a
certain member variable or the result of a certain getter method of the object.
You can do this with Field() and Property(). More specifically,

Field(&Foo::bar, m)

is a matcher that matches a Foo object whose bar member variable satisfies
matcher m.

Property(&Foo::baz, m)

is a matcher that matches a Foo object whose baz() method returns a value
that satisfies matcher m.

For example:

Note that in Property(&Foo::baz, ...), method baz() must take no argument
and be declared as const. Don’t use Property() against member functions that
you do not own, because taking addresses of functions is fragile and generally
not part of the contract of the function.

Field() and Property() can also match plain pointers to objects. For
instance,

using ::testing::Field;
using ::testing::Ge;
...
Field(&Foo::number, Ge(3))

matches a plain pointer p where p->number >= 3. If p is NULL, the match
will always fail regardless of the inner matcher.

What if you want to validate more than one members at the same time? Remember
that there are AllOf() and AllOfArray().

Finally Field() and Property() provide overloads that take the field or
property names as the first argument to include it in the error message. This
can be useful when creating combined matchers.

using ::testing::AllOf;
using ::testing::Field;
using ::testing::Matcher;
using ::testing::SafeMatcherCast;
Matcher<Foo> IsFoo(const Foo& foo) {
  return AllOf(Field("some_field", &Foo::some_field, foo.some_field),
               Field("other_field", &Foo::other_field, foo.other_field),
               Field("last_field", &Foo::last_field, foo.last_field));
}

Validating the Value Pointed to by a Pointer Argument

C++ functions often take pointers as arguments. You can use matchers like
IsNull(), NotNull(), and other comparison matchers to match a pointer, but
what if you want to make sure the value pointed to by the pointer, instead of
the pointer itself, has a certain property? Well, you can use the Pointee(m)
matcher.

Pointee(m) matches a pointer if and only if m matches the value the pointer
points to. For example:

using ::testing::Ge;
using ::testing::Pointee;
...
  EXPECT_CALL(foo, Bar(Pointee(Ge(3))));

expects foo.Bar() to be called with a pointer that points to a value greater
than or equal to 3.

One nice thing about Pointee() is that it treats a NULL pointer as a match
failure, so you can write Pointee(m) instead of

using ::testing::AllOf;
using ::testing::NotNull;
using ::testing::Pointee;
...
  AllOf(NotNull(), Pointee(m))

without worrying that a NULL pointer will crash your test.

Also, did we tell you that Pointee() works with both raw pointers and
smart pointers (std::unique_ptr, std::shared_ptr, etc)?

What if you have a pointer to pointer? You guessed it - you can use nested
Pointee() to probe deeper inside the value. For example,
Pointee(Pointee(Lt(3))) matches a pointer that points to a pointer that points
to a number less than 3 (what a mouthful…).

Testing a Certain Property of an Object

Sometimes you want to specify that an object argument has a certain property,
but there is no existing matcher that does this. If you want good error
messages, you should define a matcher. If you want to do it
quick and dirty, you could get away with writing an ordinary function.

Let’s say you have a mock function that takes an object of type Foo, which has
an int bar() method and an int baz() method, and you want to constrain that
the argument’s bar() value plus its baz() value is a given number. Here’s
how you can define a matcher to do it:

using ::testing::Matcher;
class BarPlusBazEqMatcher {
 public:
  explicit BarPlusBazEqMatcher(int expected_sum)
      : expected_sum_(expected_sum) {}
  bool MatchAndExplain(const Foo& foo,
                       std::ostream* /* listener */) const {
    return (foo.bar() + foo.baz()) == expected_sum_;
  }
  void DescribeTo(std::ostream& os) const {
    os << "bar() + baz() equals " << expected_sum_;
  }
  void DescribeNegationTo(std::ostream& os) const {
    os << "bar() + baz() does not equal " << expected_sum_;
  }
 private:
  const int expected_sum_;
};
Matcher<const Foo&> BarPlusBazEq(int expected_sum) {
  return BarPlusBazEqMatcher(expected_sum);
}
...
  EXPECT_CALL(..., DoThis(BarPlusBazEq(5)))...;

Matching Containers

Sometimes an STL container (e.g. list, vector, map, …) is passed to a mock
function and you may want to validate it. Since most STL containers support the
== operator, you can write Eq(expected_container) or simply
expected_container to match a container exactly.

Sometimes, though, you may want to be more flexible (for example, the first
element must be an exact match, but the second element can be any positive
number, and so on). Also, containers used in tests often have a small number of
elements, and having to define the expected container out-of-line is a bit of a
hassle.

You can use the ElementsAre() or UnorderedElementsAre() matcher in such
cases:

using ::testing::_;
using ::testing::ElementsAre;
using ::testing::Gt;
...
  MOCK_METHOD(void, Foo, (const vector<int>& numbers), (override));
...
  EXPECT_CALL(mock, Foo(ElementsAre(1, Gt(0), _, 5)));

The above matcher says that the container must have 4 elements, which must be 1,
greater than 0, anything, and 5 respectively.

If you instead write:

using ::testing::_;
using ::testing::Gt;
using ::testing::UnorderedElementsAre;
...
  MOCK_METHOD(void, Foo, (const vector<int>& numbers), (override));
...
  EXPECT_CALL(mock, Foo(UnorderedElementsAre(1, Gt(0), _, 5)));

It means that the container must have 4 elements, which (under some permutation)
must be 1, greater than 0, anything, and 5 respectively.

As an alternative you can place the arguments in a C-style array and use
ElementsAreArray() or UnorderedElementsAreArray() instead:

using ::testing::ElementsAreArray;
...
  // ElementsAreArray accepts an array of element values.
  const int expected_vector1[] = {1, 5, 2, 4, ...};
  EXPECT_CALL(mock, Foo(ElementsAreArray(expected_vector1)));
  // Or, an array of element matchers.
  Matcher<int> expected_vector2[] = {1, Gt(2), _, 3, ...};
  EXPECT_CALL(mock, Foo(ElementsAreArray(expected_vector2)));

In case the array needs to be dynamically created (and therefore the array size
cannot be inferred by the compiler), you can give ElementsAreArray() an
additional argument to specify the array size:

using ::testing::ElementsAreArray;
...
  int* const expected_vector3 = new int[count];
  ... fill expected_vector3 with values ...
  EXPECT_CALL(mock, Foo(ElementsAreArray(expected_vector3, count)));

Use Pair when comparing maps or other associative containers.

{% raw %}

using testing::ElementsAre;
using testing::Pair;
...
  std::map<string, int> m = {{"a", 1}, {"b", 2}, {"c", 3}};
  EXPECT_THAT(m, ElementsAre(Pair("a", 1), Pair("b", 2), Pair("c", 3)));

{% endraw %}

Tips:

• ElementsAre*() can be used to match any container that implements the
  STL iterator pattern (i.e. it has a const_iterator type and supports
  begin()/end()), not just the ones defined in STL. It will even work with
  container types yet to be written - as long as they follows the above
  pattern.
• You can use nested ElementsAre*() to match nested (multi-dimensional)
  containers.
• If the container is passed by pointer instead of by reference, just write
  Pointee(ElementsAre*(...)).
• The order of elements matters for ElementsAre*(). If you are using it
  with containers whose element order are undefined (e.g. hash_map) you
  should use WhenSorted around ElementsAre.

Sharing Matchers

Under the hood, a gMock matcher object consists of a pointer to a ref-counted
implementation object. Copying matchers is allowed and very efficient, as only
the pointer is copied. When the last matcher that references the implementation
object dies, the implementation object will be deleted.

Therefore, if you have some complex matcher that you want to use again and
again, there is no need to build it every time. Just assign it to a matcher
variable and use that variable repeatedly! For example,

using ::testing::AllOf;
using ::testing::Gt;
using ::testing::Le;
using ::testing::Matcher;
...
  Matcher<int> in_range = AllOf(Gt(5), Le(10));
  ... use in_range as a matcher in multiple EXPECT_CALLs ...

Matchers must have no side-effects {#PureMatchers}

{: .callout .warning}
WARNING: gMock does not guarantee when or how many times a matcher will be
invoked. Therefore, all matchers must be purely functional: they cannot have
any side effects, and the match result must not depend on anything other than
the matcher’s parameters and the value being matched.

This requirement must be satisfied no matter how a matcher is defined (e.g., if
it is one of the standard matchers, or a custom matcher). In particular, a
matcher can never call a mock function, as that will affect the state of the
mock object and gMock.

Setting Expectations

Knowing When to Expect {#UseOnCall}

ON_CALL is likely the single most under-utilized construct in gMock.

There are basically two constructs for defining the behavior of a mock object:
ON_CALL and EXPECT_CALL. The difference? ON_CALL defines what happens when
a mock method is called, but doesn’t imply any expectation on the method
being called. EXPECT_CALL not only defines the behavior, but also sets an
expectation that the method will be called with the given arguments, for the
given number of times (and in the given order when you specify the order
too).

Since EXPECT_CALL does more, isn’t it better than ON_CALL? Not really. Every
EXPECT_CALL adds a constraint on the behavior of the code under test. Having
more constraints than necessary is baaad - even worse than not having enough
constraints.

This may be counter-intuitive. How could tests that verify more be worse than
tests that verify less? Isn’t verification the whole point of tests?

The answer lies in what a test should verify. A good test verifies the
contract of the code. If a test over-specifies, it doesn’t leave enough
freedom to the implementation. As a result, changing the implementation without
breaking the contract (e.g. refactoring and optimization), which should be
perfectly fine to do, can break such tests. Then you have to spend time fixing
them, only to see them broken again the next time the implementation is changed.

Keep in mind that one doesn’t have to verify more than one property in one test.
In fact, it’s a good style to verify only one thing in one test. If you do
that, a bug will likely break only one or two tests instead of dozens (which
case would you rather debug?). If you are also in the habit of giving tests
descriptive names that tell what they verify, you can often easily guess what’s
wrong just from the test log itself.

So use ON_CALL by default, and only use EXPECT_CALL when you actually intend
to verify that the call is made. For example, you may have a bunch of ON_CALLs
in your test fixture to set the common mock behavior shared by all tests in the
same group, and write (scarcely) different EXPECT_CALLs in different TEST_Fs
to verify different aspects of the code’s behavior. Compared with the style
where each TEST has many EXPECT_CALLs, this leads to tests that are more
resilient to implementational changes (and thus less likely to require
maintenance) and makes the intent of the tests more obvious (so they are easier
to maintain when you do need to maintain them).

If you are bothered by the “Uninteresting mock function call” message printed
when a mock method without an EXPECT_CALL is called, you may use a NiceMock
instead to suppress all such messages for the mock object, or suppress the
message for specific methods by adding EXPECT_CALL(...).Times(AnyNumber()). DO
NOT suppress it by blindly adding an EXPECT_CALL(...), or you’ll have a test
that’s a pain to maintain.

Ignoring Uninteresting Calls

If you are not interested in how a mock method is called, just don’t say
anything about it. In this case, if the method is ever called, gMock will
perform its default action to allow the test program to continue. If you are not
happy with the default action taken by gMock, you can override it using
DefaultValue<T>::Set() (described here) or ON_CALL().

Please note that once you expressed interest in a particular mock method (via
EXPECT_CALL()), all invocations to it must match some expectation. If this
function is called but the arguments don’t match any EXPECT_CALL() statement,
it will be an error.

Disallowing Unexpected Calls

If a mock method shouldn’t be called at all, explicitly say so:

using ::testing::_;
...
  EXPECT_CALL(foo, Bar(_))
      .Times(0);

If some calls to the method are allowed, but the rest are not, just list all the
expected calls:

using ::testing::AnyNumber;
using ::testing::Gt;
...
  EXPECT_CALL(foo, Bar(5));
  EXPECT_CALL(foo, Bar(Gt(10)))
      .Times(AnyNumber());

A call to foo.Bar() that doesn’t match any of the EXPECT_CALL() statements
will be an error.

Understanding Uninteresting vs Unexpected Calls {#uninteresting-vs-unexpected}

Uninteresting calls and unexpected calls are different concepts in gMock.
Very different.

A call x.Y(...) is uninteresting if there’s not even a single
EXPECT_CALL(x, Y(...)) set. In other words, the test isn’t interested in the
x.Y() method at all, as evident in that the test doesn’t care to say anything
about it.

A call x.Y(...) is unexpected if there are some EXPECT_CALL(x, Y(...))s set, but none of them matches the call. Put another way, the test is
interested in the x.Y() method (therefore it explicitly sets some
EXPECT_CALL to verify how it’s called); however, the verification fails as the
test doesn’t expect this particular call to happen.

An unexpected call is always an error, as the code under test doesn’t behave
the way the test expects it to behave.

By default, an uninteresting call is not an error, as it violates no
constraint specified by the test. (gMock’s philosophy is that saying nothing
means there is no constraint.) However, it leads to a warning, as it might
indicate a problem (e.g. the test author might have forgotten to specify a
constraint).

In gMock, NiceMock and StrictMock can be used to make a mock class “nice” or
“strict”. How does this affect uninteresting calls and unexpected calls?

A nice mock suppresses uninteresting call warnings. It is less chatty than
the default mock, but otherwise is the same. If a test fails with a default
mock, it will also fail using a nice mock instead. And vice versa. Don’t expect
making a mock nice to change the test’s result.

A strict mock turns uninteresting call warnings into errors. So making a
mock strict may change the test’s result.

Let’s look at an example:

TEST(...) {
  NiceMock<MockDomainRegistry> mock_registry;
  EXPECT_CALL(mock_registry, GetDomainOwner("google.com"))
          .WillRepeatedly(Return("Larry Page"));
  // Use mock_registry in code under test.
  ... &mock_registry ...
}

The sole EXPECT_CALL here says that all calls to GetDomainOwner() must have
"google.com" as the argument. If GetDomainOwner("yahoo.com") is called, it
will be an unexpected call, and thus an error. Having a nice mock doesn’t
change the severity of an unexpected call.

So how do we tell gMock that GetDomainOwner() can be called with some other
arguments as well? The standard technique is to add a “catch all” EXPECT_CALL:

  EXPECT_CALL(mock_registry, GetDomainOwner(_))
        .Times(AnyNumber());  // catches all other calls to this method.
  EXPECT_CALL(mock_registry, GetDomainOwner("google.com"))
        .WillRepeatedly(Return("Larry Page"));

Remember that _ is the wildcard matcher that matches anything. With this, if
GetDomainOwner("google.com") is called, it will do what the second
EXPECT_CALL says; if it is called with a different argument, it will do what
the first EXPECT_CALL says.

Note that the order of the two EXPECT_CALLs is important, as a newer
EXPECT_CALL takes precedence over an older one.

For more on uninteresting calls, nice mocks, and strict mocks, read
“The Nice, the Strict, and the Naggy”.

Ignoring Uninteresting Arguments {#ParameterlessExpectations}

If your test doesn’t care about the parameters (it only cares about the number
or order of calls), you can often simply omit the parameter list:

  // Expect foo.Bar( ... ) twice with any arguments.
  EXPECT_CALL(foo, Bar).Times(2);
  // Delegate to the given method whenever the factory is invoked.
  ON_CALL(foo_factory, MakeFoo)
      .WillByDefault(&BuildFooForTest);

This functionality is only available when a method is not overloaded; to prevent
unexpected behavior it is a compilation error to try to set an expectation on a
method where the specific overload is ambiguous. You can work around this by
supplying a simpler mock interface than the mocked class
provides.

This pattern is also useful when the arguments are interesting, but match logic
is substantially complex. You can leave the argument list unspecified and use
SaveArg actions to save the values for later verification. If
you do that, you can easily differentiate calling the method the wrong number of
times from calling it with the wrong arguments.

Expecting Ordered Calls {#OrderedCalls}

Although an EXPECT_CALL() statement defined later takes precedence when gMock
tries to match a function call with an expectation, by default calls don’t have
to happen in the order EXPECT_CALL() statements are written. For example, if
the arguments match the matchers in the second EXPECT_CALL(), but not those in
the first and third, then the second expectation will be used.

If you would rather have all calls occur in the order of the expectations, put
the EXPECT_CALL() statements in a block where you define a variable of type
InSequence:

using ::testing::_;
using ::testing::InSequence;
  {
    InSequence s;
    EXPECT_CALL(foo, DoThis(5));
    EXPECT_CALL(bar, DoThat(_))
        .Times(2);
    EXPECT_CALL(foo, DoThis(6));
  }

In this example, we expect a call to foo.DoThis(5), followed by two calls to
bar.DoThat() where the argument can be anything, which are in turn followed by
a call to foo.DoThis(6). If a call occurred out-of-order, gMock will report an
error.

Expecting Partially Ordered Calls {#PartialOrder}

Sometimes requiring everything to occur in a predetermined order can lead to
brittle tests. For example, we may care about A occurring before both B and
C, but aren’t interested in the relative order of B and C. In this case,
the test should reflect our real intent, instead of being overly constraining.

gMock allows you to impose an arbitrary DAG (directed acyclic graph) on the
calls. One way to express the DAG is to use the
After clause of EXPECT_CALL.

Another way is via the InSequence() clause (not the same as the InSequence
class), which we borrowed from jMock 2. It’s less flexible than After(), but
more convenient when you have long chains of sequential calls, as it doesn’t
require you to come up with different names for the expectations in the chains.
Here’s how it works:

If we view EXPECT_CALL() statements as nodes in a graph, and add an edge from
node A to node B wherever A must occur before B, we can get a DAG. We use the
term “sequence” to mean a directed path in this DAG. Now, if we decompose the
DAG into sequences, we just need to know which sequences each EXPECT_CALL()
belongs to in order to be able to reconstruct the original DAG.

So, to specify the partial order on the expectations we need to do two things:
first to define some Sequence objects, and then for each EXPECT_CALL() say
which Sequence objects it is part of.

Expectations in the same sequence must occur in the order they are written. For
example,

using ::testing::Sequence;
...
  Sequence s1, s2;
  EXPECT_CALL(foo, A())
      .InSequence(s1, s2);
  EXPECT_CALL(bar, B())
      .InSequence(s1);
  EXPECT_CALL(bar, C())
      .InSequence(s2);
  EXPECT_CALL(foo, D())
      .InSequence(s2);

specifies the following DAG (where s1 is A -> B, and s2 is A -> C -> D):

       +---> B
       |
  A ---|
       |
       +---> C ---> D

This means that A must occur before B and C, and C must occur before D. There’s
no restriction about the order other than these.

Controlling When an Expectation Retires

When a mock method is called, gMock only considers expectations that are still
active. An expectation is active when created, and becomes inactive (aka
retires) when a call that has to occur later has occurred. For example, in

using ::testing::_;
using ::testing::Sequence;
...
  Sequence s1, s2;
  EXPECT_CALL(log, Log(WARNING, _, "File too large."))      // #1
      .Times(AnyNumber())
      .InSequence(s1, s2);
  EXPECT_CALL(log, Log(WARNING, _, "Data set is empty."))   // #2
      .InSequence(s1);
  EXPECT_CALL(log, Log(WARNING, _, "User not found."))      // #3
      .InSequence(s2);

as soon as either #2 or #3 is matched, #1 will retire. If a warning "File too large." is logged after this, it will be an error.

Note that an expectation doesn’t retire automatically when it’s saturated. For
example,

using ::testing::_;
...
  EXPECT_CALL(log, Log(WARNING, _, _));                     // #1
  EXPECT_CALL(log, Log(WARNING, _, "File too large."));     // #2

says that there will be exactly one warning with the message "File too large.". If the second warning contains this message too, #2 will match again
and result in an upper-bound-violated error.

If this is not what you want, you can ask an expectation to retire as soon as it
becomes saturated:

using ::testing::_;
...
  EXPECT_CALL(log, Log(WARNING, _, _));                     // #1
  EXPECT_CALL(log, Log(WARNING, _, "File too large."))      // #2
      .RetiresOnSaturation();

Here #2 can be used only once, so if you have two warnings with the message
"File too large.", the first will match #2 and the second will match #1 -
there will be no error.

Using Actions

Returning References from Mock Methods

If a mock function’s return type is a reference, you need to use ReturnRef()
instead of Return() to return a result:

using ::testing::ReturnRef;
class MockFoo : public Foo {
 public:
  MOCK_METHOD(Bar&, GetBar, (), (override));
};
...
  MockFoo foo;
  Bar bar;
  EXPECT_CALL(foo, GetBar())
      .WillOnce(ReturnRef(bar));
...

Returning Live Values from Mock Methods

The Return(x) action saves a copy of x when the action is created, and
always returns the same value whenever it’s executed. Sometimes you may want to
instead return the live value of x (i.e. its value at the time when the
action is executed.). Use either ReturnRef() or ReturnPointee() for this
purpose.

If the mock function’s return type is a reference, you can do it using
ReturnRef(x), as shown in the previous recipe (“Returning References from Mock
Methods”). However, gMock doesn’t let you use ReturnRef() in a mock function
whose return type is not a reference, as doing that usually indicates a user
error. So, what shall you do?

Though you may be tempted, DO NOT use std::ref():

using testing::Return;
class MockFoo : public Foo {
 public:
  MOCK_METHOD(int, GetValue, (), (override));
};
...
  int x = 0;
  MockFoo foo;
  EXPECT_CALL(foo, GetValue())
      .WillRepeatedly(Return(std::ref(x)));  // Wrong!
  x = 42;
  EXPECT_EQ(42, foo.GetValue());

Unfortunately, it doesn’t work here. The above code will fail with error:

Value of: foo.GetValue()
  Actual: 0
Expected: 42

The reason is that Return(*value*) converts value to the actual return type
of the mock function at the time when the action is created, not when it is
executed. (This behavior was chosen for the action to be safe when value is
a proxy object that references some temporary objects.) As a result,
std::ref(x) is converted to an int value (instead of a const int&) when
the expectation is set, and Return(std::ref(x)) will always return 0.

ReturnPointee(pointer) was provided to solve this problem specifically. It
returns the value pointed to by pointer at the time the action is executed:

using testing::ReturnPointee;
...
  int x = 0;
  MockFoo foo;
  EXPECT_CALL(foo, GetValue())
      .WillRepeatedly(ReturnPointee(&x));  // Note the & here.
  x = 42;
  EXPECT_EQ(42, foo.GetValue());  // This will succeed now.

Combining Actions

Want to do more than one thing when a function is called? That’s fine. DoAll()
allow you to do sequence of actions every time. Only the return value of the
last action in the sequence will be used.

using ::testing::_;
using ::testing::DoAll;
class MockFoo : public Foo {
 public:
  MOCK_METHOD(bool, Bar, (int n), (override));
};
...
  EXPECT_CALL(foo, Bar(_))
      .WillOnce(DoAll(action_1,
                      action_2,
                      ...
                      action_n));

Verifying Complex Arguments {#SaveArgVerify}

If you want to verify that a method is called with a particular argument but the
match criteria is complex, it can be difficult to distinguish between
cardinality failures (calling the method the wrong number of times) and argument
match failures. Similarly, if you are matching multiple parameters, it may not
be easy to distinguishing which argument failed to match. For example:

  // Not ideal: this could fail because of a problem with arg1 or arg2, or maybe
  // just the method wasn't called.
  EXPECT_CALL(foo, SendValues(_, ElementsAre(1, 4, 4, 7), EqualsProto( ... )));

You can instead save the arguments and test them individually:

  EXPECT_CALL(foo, SendValues)
      .WillOnce(DoAll(SaveArg<1>(&actual_array), SaveArg<2>(&actual_proto)));
  ... run the test
  EXPECT_THAT(actual_array, ElementsAre(1, 4, 4, 7));
  EXPECT_THAT(actual_proto, EqualsProto( ... ));

Mocking Side Effects {#MockingSideEffects}

Sometimes a method exhibits its effect not via returning a value but via side
effects. For example, it may change some global state or modify an output
argument. To mock side effects, in general you can define your own action by
implementing ::testing::ActionInterface.

If all you need to do is to change an output argument, the built-in
SetArgPointee() action is convenient:

using ::testing::_;
using ::testing::SetArgPointee;
class MockMutator : public Mutator {
 public:
  MOCK_METHOD(void, Mutate, (bool mutate, int* value), (override));
  ...
}
...
  MockMutator mutator;
  EXPECT_CALL(mutator, Mutate(true, _))
      .WillOnce(SetArgPointee<1>(5));

In this example, when mutator.Mutate() is called, we will assign 5 to the
int variable pointed to by argument #1 (0-based).

SetArgPointee() conveniently makes an internal copy of the value you pass to
it, removing the need to keep the value in scope and alive. The implication
however is that the value must have a copy constructor and assignment operator.

If the mock method also needs to return a value as well, you can chain
SetArgPointee() with Return() using DoAll(), remembering to put the
Return() statement last:

using ::testing::_;
using ::testing::DoAll;
using ::testing::Return;
using ::testing::SetArgPointee;
class MockMutator : public Mutator {
 public:
  ...
  MOCK_METHOD(bool, MutateInt, (int* value), (override));
}
...
  MockMutator mutator;
  EXPECT_CALL(mutator, MutateInt(_))
      .WillOnce(DoAll(SetArgPointee<0>(5),
                      Return(true)));

Note, however, that if you use the ReturnOKWith() method, it will override the
values provided by SetArgPointee() in the response parameters of your function
call.

If the output argument is an array, use the SetArrayArgument<N>(first, last)
action instead. It copies the elements in source range [first, last) to the
array pointed to by the N-th (0-based) argument:

using ::testing::NotNull;
using ::testing::SetArrayArgument;
class MockArrayMutator : public ArrayMutator {
 public:
  MOCK_METHOD(void, Mutate, (int* values, int num_values), (override));
  ...
}
...
  MockArrayMutator mutator;
  int values[5] = {1, 2, 3, 4, 5};
  EXPECT_CALL(mutator, Mutate(NotNull(), 5))
      .WillOnce(SetArrayArgument<0>(values, values + 5));

This also works when the argument is an output iterator:

using ::testing::_;
using ::testing::SetArrayArgument;
class MockRolodex : public Rolodex {
 public:
  MOCK_METHOD(void, GetNames, (std::back_insert_iterator<vector<string>>),
              (override));
  ...
}
...
  MockRolodex rolodex;
  vector<string> names = {"George", "John", "Thomas"};
  EXPECT_CALL(rolodex, GetNames(_))
      .WillOnce(SetArrayArgument<0>(names.begin(), names.end()));