-## gMock for Dummies {#GMockForDummies}
+# gMock for Dummies {#GMockForDummies}
<!-- GOOGLETEST_CM0013 DO NOT DELETE -->
-### What Is gMock?
+<!-- GOOGLETEST_CM0035 DO NOT DELETE -->
+
+## What Is gMock?
When you write a prototype or test, often it's not feasible or wise to rely on
real objects entirely. A **mock object** implements the same interface as a real
3. then you exercise code that uses the mock objects. gMock will catch any
violation to the expectations as soon as it arises.
-### Why gMock?
+## Why gMock?
While mock objects help you remove unnecessary dependencies in tests and make
them fast and reliable, using mocks manually in C++ is *hard*:
* a *testing* tool to cut your tests' outbound dependencies and probe the
interaction between your module and its collaborators.
-### Getting Started
+## Getting Started
gMock is bundled with googletest.
-### A Case for Mock Turtles
+## A Case for Mock Turtles
Let's look at an example. Suppose you are developing a graphics program that
relies on a [LOGO](http://en.wikipedia.org/wiki/Logo_programming_language)-like
```cpp
class Turtle {
...
- virtual ~Turtle() {};
+ virtual ~Turtle() {}
virtual void PenUp() = 0;
virtual void PenDown() = 0;
virtual void Forward(int distance) = 0;
maintain (the intent of a test is expressed in the code, not in some binary
images), and run *much, much faster*.
-### Writing the Mock Class
+## Writing the Mock Class
If you are lucky, the mocks you need to use have already been implemented by
some nice people. If, however, you find yourself in the position to write a mock
class, relax - gMock turns this task into a fun game! (Well, almost.)
-#### How to Define It
+### How to Define It
Using the `Turtle` interface as example, here are the simple steps you need to
follow:
You don't need to define these mock methods somewhere else - the `MOCK_METHOD`
macro will generate the definitions for you. It's that simple!
-#### Where to Put It
+### Where to Put It
When you define a mock class, you need to decide where to put its definition.
Some people put it in a `_test.cc`. This is fine when the interface being mocked
<!-- GOOGLETEST_CM0029 DO NOT DELETE -->
-### Using Mocks in Tests
+## Using Mocks in Tests
Once you have a mock class, using it is easy. The typical work flow is:
...
```
-**Tip 1:** If you run the test from an Emacs buffer, you can hit <Enter> on the
-line number to jump right to the failed expectation.
+**Tip 1:** If you run the test from an Emacs buffer, you can hit `<Enter>` on
+the line number to jump right to the failed expectation.
**Tip 2:** If your mock objects are never deleted, the final verification won't
happen. Therefore it's a good idea to turn on the heap checker in your tests
the same effect without using gMock. However, as we shall reveal soon, gMock
allows you to do *so much more* with the mocks.
-### Setting Expectations
+## Setting Expectations
The key to using a mock object successfully is to set the *right expectations*
on it. If you set the expectations too strict, your test will fail as the result
intend it to catch. gMock provides the necessary means for you to do it "just
right."
-#### General Syntax
+### General Syntax
In gMock we use the `EXPECT_CALL()` macro to set an expectation on a mock
method. The general syntax is:
reader), and second it allows gMock to include the source file location of a
failed expectation in messages, making debugging easier.
-#### Matchers: What Arguments Do We Expect?
+### Matchers: What Arguments Do We Expect?
When a mock function takes arguments, we may specify what arguments we are
expecting, for example:
In the above examples, `100` and `50` are also matchers; implicitly, they are
the same as `Eq(100)` and `Eq(50)`, which specify that the argument must be
equal (using `operator==`) to the matcher argument. There are many
-[built-in matchers](#MatcherList) for common types (as well as
+[built-in matchers](cheat_sheet.md#MatcherList) for common types (as well as
[custom matchers](cook_book.md#NewMatchers)); for example:
```cpp
arguments and possibly also the
[types of the arguments](cook_book.md#SelectOverload).
-#### Cardinalities: How Many Times Will It Be Called?
+### Cardinalities: How Many Times Will It Be Called?
The first clause we can specify following an `EXPECT_CALL()` is `Times()`. We
call its argument a **cardinality** as it tells *how many times* the call should
**Quick quiz:** what do you think will happen if a function is expected to be
called twice but actually called four times?
-#### Actions: What Should It Do?
+### Actions: What Should It Do?
Remember that a mock object doesn't really have a working implementation? We as
users have to tell it what to do when a method is invoked. This is easy in
return 100 the first time, but **return 0 from the second time on**, as
returning 0 is the default action for `int` functions.
-#### Using Multiple Expectations {#MultiExpectations}
+### Using Multiple Expectations {#MultiExpectations}
So far we've only shown examples where you have a single expectation. More
realistically, you'll specify expectations on multiple mock methods which may be
ok. See
[Understanding Uninteresting vs Unexpected Calls](cook_book.md#uninteresting-vs-unexpected).
-#### Ordered vs Unordered Calls {#OrderedCalls}
+### Ordered vs Unordered Calls {#OrderedCalls}
By default, an expectation can match a call even though an earlier expectation
hasn't been satisfied. In other words, the calls don't have to occur in the
them? Can you specify an arbitrary partial order? The answer is ... yes! The
details can be found [here](cook_book.md#OrderedCalls).)
-#### All Expectations Are Sticky (Unless Said Otherwise) {#StickyExpectations}
+### All Expectations Are Sticky (Unless Said Otherwise) {#StickyExpectations}
Now let's do a quick quiz to see how well you can use this mock stuff already.
How would you test that the turtle is asked to go to the origin *exactly twice*
sequence has been used, it automatically retires (and will never be used to
match any call).
-#### Uninteresting Calls
+### Uninteresting Calls
A mock object may have many methods, and not all of them are that interesting.
For example, in some tests we may not care about how many times `GetX()` and
projects / ceph.git / blobdiff