Fix doc links
This commit is contained in:
@@ -264,7 +264,7 @@ Notes:
|
||||
|
||||
* These matchers can also match:
|
||||
1. a native array passed by reference (e.g. in `Foo(const int (&a)[5])`), and
|
||||
1. an array passed as a pointer and a count (e.g. in `Bar(const T* buffer, int len)` -- see [Multi-argument Matchers](#Multiargument_Matchers.md)).
|
||||
1. an array passed as a pointer and a count (e.g. in `Bar(const T* buffer, int len)` -- see [Multi-argument Matchers](#multiargument-matchers)).
|
||||
* The array being matched may be multi-dimensional (i.e. its elements can be arrays).
|
||||
* `m` in `Pointwise(m, ...)` should be a matcher for `::testing::tuple<T, U>` where `T` and `U` are the element type of the actual container and the expected container, respectively. For example, to compare two `Foo` containers where `Foo` doesn't support `operator==` but has an `Equals()` method, one might write:
|
||||
|
||||
|
||||
@@ -2237,7 +2237,7 @@ Mocking a method that takes and/or returns move-only types presents some
|
||||
challenges, but nothing insurmountable. This recipe shows you how you can do it.
|
||||
Note that the support for move-only method arguments was only introduced to
|
||||
gMock in April 2017; in older code, you may find more complex
|
||||
[workarounds](#LegacyMoveOnly) for lack of this feature.
|
||||
[workarounds](#legacy-workarounds-for-move-only-types) for lack of this feature.
|
||||
|
||||
Let’s say we are working on a fictional project that lets one post and share
|
||||
snippets called “buzzes”. Your code uses these types:
|
||||
@@ -2302,7 +2302,7 @@ action:
|
||||
```
|
||||
|
||||
If you are not happy with the default action, you can tweak it as usual; see
|
||||
[Setting Default Actions](#OnCall).
|
||||
[Setting Default Actions](#setting-the-default-actions-for-a-mock-method).
|
||||
|
||||
If you just need to return a pre-defined move-only value, you can use the
|
||||
`Return(ByMove(...))` action:
|
||||
@@ -2345,7 +2345,7 @@ created and returned. You cannot do this with `Return(ByMove(...))`.
|
||||
That covers returning move-only values; but how do we work with methods
|
||||
accepting move-only arguments? The answer is that they work normally, although
|
||||
some actions will not compile when any of method's arguments are move-only. You
|
||||
can always use `Return`, or a [lambda or functor](#FunctionsAsActions):
|
||||
can always use `Return`, or a [lambda or functor](#using-functionsmethodsfunctors-as-actions):
|
||||
|
||||
```cpp
|
||||
using ::testing::Unused;
|
||||
@@ -2366,7 +2366,7 @@ implemented yet. If this is blocking you, please file a bug.
|
||||
A few actions (e.g. `DoAll`) copy their arguments internally, so they can never
|
||||
work with non-copyable objects; you'll have to use functors instead.
|
||||
|
||||
##### Legacy workarounds for move-only types {#LegacyMoveOnly}
|
||||
##### Legacy workarounds for move-only types
|
||||
|
||||
Support for move-only function arguments was only introduced to gMock in April
|
||||
2017. In older code, you may encounter the following workaround for the lack of
|
||||
@@ -2821,7 +2821,7 @@ and you should see an `OUTPUT_DIR` directory being created with files
|
||||
These three files contain everything you need to use Google Mock (and
|
||||
Google Test). Just copy them to anywhere you want and you are ready
|
||||
to write tests and use mocks. You can use the
|
||||
[scrpts/test/Makefile](../scripts/test/Makefile) file as an example on how to compile your tests
|
||||
[make/Makefile](../make/Makefile) file as an example on how to compile your tests
|
||||
against them.
|
||||
|
||||
# Extending Google Mock #
|
||||
@@ -3655,6 +3655,6 @@ This printer knows how to print built-in C++ types, native arrays, STL
|
||||
containers, and any type that supports the `<<` operator. For other
|
||||
types, it prints the raw bytes in the value and hopes that you the
|
||||
user can figure it out.
|
||||
[Google Test's advanced guide](../../googletest/docs/advanced.md#teaching-google-test-how-to-print-your-values)
|
||||
[Google Test's advanced guide](../../googletest/docs/advanced.md#teaching-googletest-how-to-print-your-values)
|
||||
explains how to extend the printer to do a better job at
|
||||
printing your particular type than to dump the bytes.
|
||||
|
||||
@@ -11,5 +11,5 @@ the respective git branch/tag).**
|
||||
|
||||
To contribute code to Google Mock, read:
|
||||
|
||||
* [CONTRIBUTING](../CONTRIBUTING.md) -- read this _before_ writing your first patch.
|
||||
* [CONTRIBUTING](../../CONTRIBUTING.md) -- read this _before_ writing your first patch.
|
||||
* [Pump Manual](../../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files.
|
||||
|
||||
@@ -187,7 +187,7 @@ sometimes causes the test program to crash. You'll still be able to
|
||||
notice that the test has failed, but it's not a graceful failure.
|
||||
|
||||
A better solution is to use Google Test's
|
||||
[event listener API](../../googletest/docs/advanced.md#extending-google-test-by-handling-test-events)
|
||||
[event listener API](../../googletest/docs/advanced.md#extending-googletest-by-handling-test-events)
|
||||
to report a test failure to your testing framework properly. You'll need to
|
||||
implement the `OnTestPartResult()` method of the event listener interface, but it
|
||||
should be straightforward.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Please send your questions to the
|
||||
[googlemock](http://groups.google.com/group/googlemock) discussion
|
||||
group. If you need help with compiler errors, make sure you have
|
||||
tried [Google Mock Doctor](#How_am_I_supposed_to_make_sense_of_these_horrible_template_error.md) first.
|
||||
tried [Google Mock Doctor](#how-am-i-supposed-to-make-sense-of-these-horrible-template-errors) first.
|
||||
|
||||
## When I call a method on my mock object, the method for the real object is invoked instead. What's the problem? ##
|
||||
|
||||
@@ -474,10 +474,10 @@ verbose level.
|
||||
If you find yourself needing to perform some action that's not
|
||||
supported by Google Mock directly, remember that you can define your own
|
||||
actions using
|
||||
[MakeAction()](CookBook.md#writing-new-actions) or
|
||||
[MakePolymorphicAction()](CookBook.md#writing_new_polymorphic_actions),
|
||||
[MakeAction()](CookBook.md#writing-new-actions-quickly) or
|
||||
[MakePolymorphicAction()](CookBook.md#writing-new-polymorphic-actions),
|
||||
or you can write a stub function and invoke it using
|
||||
[Invoke()](CookBook.md#using-functions_methods_functors).
|
||||
[Invoke()](CookBook.md#using-functionsmethodsfunctors-as-actions).
|
||||
|
||||
## MOCK\_METHODn()'s second argument looks funny. Why don't you use the MOCK\_METHODn(Method, return\_type, arg\_1, ..., arg\_n) syntax? ##
|
||||
|
||||
@@ -599,7 +599,7 @@ when the mock method is called. `SetArgPointee()` says what the
|
||||
side effect is, but doesn't say what the return value should be. You
|
||||
need `DoAll()` to chain a `SetArgPointee()` with a `Return()`.
|
||||
|
||||
See this [recipe](CookBook.md#mocking_side_effects) for more details and an example.
|
||||
See this [recipe](CookBook.md#mocking-side-effects) for more details and an example.
|
||||
|
||||
|
||||
## My question is not in your FAQ! ##
|
||||
|
||||
Reference in New Issue
Block a user