aboutsummaryrefslogtreecommitdiffstats
path: root/googlemock/docs/for_dummies.md
diff options
context:
space:
mode:
Diffstat (limited to 'googlemock/docs/for_dummies.md')
-rw-r--r--googlemock/docs/for_dummies.md18
1 files changed, 10 insertions, 8 deletions
diff --git a/googlemock/docs/for_dummies.md b/googlemock/docs/for_dummies.md
index 3bccd2bd..93cf06f3 100644
--- a/googlemock/docs/for_dummies.md
+++ b/googlemock/docs/for_dummies.md
@@ -148,8 +148,8 @@ follow:
* Derive a class `MockTurtle` from `Turtle`.
* Take a *virtual* function of `Turtle` (while it's possible to
- [mock non-virtual methods using templates](#MockingNonVirtualMethods), it's
- much more involved).
+ [mock non-virtual methods using templates](cook_book.md#MockingNonVirtualMethods),
+ it's much more involved).
* In the `public:` section of the child class, write `MOCK_METHOD();`
* Now comes the fun part: you take the function signature, cut-and-paste it
into the macro, and add two commas - one between the return type and the
@@ -213,7 +213,7 @@ specific domain much better than `Foo` does.
Once you have a mock class, using it is easy. The typical work flow is:
1. Import the gMock names from the `testing` namespace such that you can use
- them unqualified (You only have to do it once per file. Remember that
+ them unqualified (You only have to do it once per file). Remember that
namespaces are a good idea.
2. Create some mock objects.
3. Specify your expectations on them (How many times will a method be called?
@@ -375,7 +375,7 @@ 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
-[custom matchers](#NewMatchers)); for example:
+[custom matchers](cook_book.md#NewMatchers)); for example:
```cpp
using ::testing::Ge;
@@ -396,7 +396,8 @@ EXPECT_CALL(turtle, GoTo);
This works for all non-overloaded methods; if a method is overloaded, you need
to help gMock resolve which overload is expected by specifying the number of
-arguments and possibly also the [types of the arguments](#SelectOverload).
+arguments and possibly also the
+[types of the arguments](cook_book.md#SelectOverload).
#### Cardinalities: How Many Times Will It Be Called?
@@ -412,7 +413,8 @@ gMock will report a googletest failure whenever the function is (wrongfully)
called.
We've seen `AtLeast(n)` as an example of fuzzy cardinalities earlier. For the
-list of built-in cardinalities you can use, see [here](#CardinalityList).
+list of built-in cardinalities you can use, see
+[here](cheat_sheet.md#CardinalityList).
The `Times()` clause can be omitted. **If you omit `Times()`, gMock will infer
the cardinality for you.** The rules are easy to remember:
@@ -481,7 +483,7 @@ the *default* action for the function every time (unless, of course, you have a
What can we do inside `WillOnce()` besides `Return()`? You can return a
reference using `ReturnRef(*variable*)`, or invoke a pre-defined function, among
-[others](#ActionList).
+[others](cook_book.md#using-actions).
**Important note:** The `EXPECT_CALL()` statement evaluates the action clause
only once, even though the action may be performed many times. Therefore you
@@ -559,7 +561,7 @@ overloaded). This makes any calls to the method expected. This is not necessary
for methods that are not mentioned at all (these are "uninteresting"), but is
useful for methods that have some expectations, but for which other calls are
ok. See
-[Understanding Uninteresting vs Unexpected Calls](#uninteresting-vs-unexpected).
+[Understanding Uninteresting vs Unexpected Calls](cook_book.md#uninteresting-vs-unexpected).
#### Ordered vs Unordered Calls {#OrderedCalls}