Fix some broken links in docs
This commit is contained in:
Hyuk Myeong
parent
58c7197761
commit
308337e69f
googlemock/docs
googletest/docs
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
### Defining a Mock Class
|
||||
|
||||
#### Mocking a Normal Class {#MockClass}
|
||||
#### Mocking a Normal Class
|
||||
|
||||
Given
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ StrictMock<MockFoo> strict_foo; // The type is a subclass of MockFoo.
|
|||
**Note:** A mock object is currently naggy by default. We may make it nice by
|
||||
default in the future.
|
||||
|
||||
#### Mocking a Class Template {#MockTemplate}
|
||||
#### Mocking a Class Template
|
||||
|
||||
Class templates can be mocked just like any class.
|
||||
|
||||
|
|
@ -94,7 +94,7 @@ For example,
|
|||
|
||||
where `STDMETHODCALLTYPE` is defined by `<objbase.h>` on Windows.
|
||||
|
||||
### Using Mocks in Tests {#UsingMocks}
|
||||
### Using Mocks in Tests
|
||||
|
||||
The typical work flow is:
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ TEST(BarTest, DoesThis) {
|
|||
} // #6
|
||||
```
|
||||
|
||||
### Setting Default Actions {#OnCall}
|
||||
### Setting Default Actions
|
||||
|
||||
gMock has a **built-in default action** for any function that returns `void`,
|
||||
`bool`, a numeric value, or a pointer. In C++11, it will additionally returns
|
||||
|
|
@ -177,7 +177,7 @@ Example usage:
|
|||
To customize the default action for a particular method of a specific mock
|
||||
object, use `ON_CALL()`. `ON_CALL()` has a similar syntax to `EXPECT_CALL()`,
|
||||
but it is used for setting default behaviors (when you do not require that the
|
||||
mock method is called). See [here](cook_book.md#UseOnCall) for a more detailed
|
||||
mock method is called). See [here](cook_book.md#knowing-when-to-expect) for a more detailed
|
||||
discussion.
|
||||
|
||||
```cpp
|
||||
|
|
@ -186,7 +186,7 @@ ON_CALL(mock-object, method(matchers))
|
|||
.WillByDefault(action);
|
||||
```
|
||||
|
||||
### Setting Expectations {#ExpectCall}
|
||||
### Setting Expectations
|
||||
|
||||
`EXPECT_CALL()` sets **expectations** on a mock method (How will it be called?
|
||||
What will it do?):
|
||||
|
|
@ -225,7 +225,7 @@ If `Times()` is omitted, the cardinality is assumed to be:
|
|||
A method with no `EXPECT_CALL()` is free to be invoked *any number of times*,
|
||||
and the default action will be taken each time.
|
||||
|
||||
### Matchers {#MatcherList}
|
||||
### Matchers
|
||||
|
||||
<!-- GOOGLETEST_CM0020 DO NOT DELETE -->
|
||||
|
||||
|
|
@ -278,7 +278,7 @@ copy constructor, try wrap it in `ByRef()`, e.g.
|
|||
`Eq(ByRef(non_copyable_value))`. If you do that, make sure `non_copyable_value`
|
||||
is not changed afterwards, or the meaning of your matcher will be changed.
|
||||
|
||||
#### Floating-Point Matchers {#FpMatchers}
|
||||
#### Floating-Point Matchers
|
||||
|
||||
<!-- mdformat off(no multiline tables) -->
|
||||
| Matcher | Description |
|
||||
|
|
@ -363,7 +363,7 @@ messages, you can use:
|
|||
1. a native array passed by reference (e.g. in `Foo(const int (&a)[5])`),
|
||||
and
|
||||
2. an array passed as a pointer and a count (e.g. in `Bar(const T* buffer,
|
||||
int len)` -- see [Multi-argument Matchers](#MultiArgMatchers)).
|
||||
int len)` -- see [Multi-argument Matchers](#multi-argument-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 `::std::tuple<T, U>`
|
||||
|
|
@ -412,7 +412,7 @@ messages, you can use:
|
|||
|
||||
<!-- GOOGLETEST_CM0027 DO NOT DELETE -->
|
||||
|
||||
#### Multi-argument Matchers {#MultiArgMatchers}
|
||||
#### Multi-argument Matchers
|
||||
|
||||
Technically, all matchers match a *single* value. A "multi-argument" matcher is
|
||||
just one that matches a *tuple*. The following matchers can be used to match a
|
||||
|
|
@ -466,7 +466,7 @@ You can make a matcher from one or more other matchers:
|
|||
`AddressSatisfies(callback)` and `Truly(callback)` take ownership of `callback`,
|
||||
which must be a permanent callback.
|
||||
|
||||
#### Using Matchers as Predicates {#MatchersAsPredicatesCheat}
|
||||
#### Using Matchers as Predicates
|
||||
|
||||
<!-- mdformat off(no multiline tables) -->
|
||||
| Matcher | Description |
|
||||
|
|
@ -495,7 +495,7 @@ which must be a permanent callback.
|
|||
3. You can use `PrintToString(x)` to convert a value `x` of any type to a
|
||||
string.
|
||||
|
||||
### Actions {#ActionList}
|
||||
### Actions
|
||||
|
||||
**Actions** specify what a mock function should do when invoked.
|
||||
|
||||
|
|
@ -635,7 +635,7 @@ composite action - trying to do so will result in a run-time error.
|
|||
|
||||
The `ACTION*` macros cannot be used inside a function or class.
|
||||
|
||||
### Cardinalities {#CardinalityList}
|
||||
### Cardinalities
|
||||
|
||||
These are used in `Times()` to specify how many times a mock function will be
|
||||
called:
|
||||
|
|
@ -656,7 +656,7 @@ By default, the expectations can be matched in *any* order. If some or all
|
|||
expectations must be matched in a given order, there are two ways to specify it.
|
||||
They can be used either independently or together.
|
||||
|
||||
#### The After Clause {#AfterClause}
|
||||
#### The After Clause
|
||||
|
||||
```cpp
|
||||
using ::testing::Expectation;
|
||||
|
|
@ -690,7 +690,7 @@ says that `Bar()` can be called only after all elements have been initialized
|
|||
Modifying an `ExpectationSet` after using it in an `.After()` doesn't affect the
|
||||
meaning of the `.After()`.
|
||||
|
||||
#### Sequences {#UsingSequences}
|
||||
#### Sequences
|
||||
|
||||
When you have a long chain of sequential expectations, it's easier to specify
|
||||
the order using **sequences**, which don't require you to given each expectation
|
||||
|
|
|
|||
|
|
@ -175,7 +175,7 @@ class MockStack : public StackInterface<Elem> {
|
|||
};
|
||||
```
|
||||
|
||||
### Mocking Non-virtual Methods {#MockingNonVirtualMethods}
|
||||
### Mocking Non-virtual Methods
|
||||
|
||||
gMock can mock non-virtual functions to be used in Hi-perf dependency
|
||||
injection.<!-- GOOGLETEST_CM0017 DO NOT DELETE -->
|
||||
|
|
@ -277,7 +277,7 @@ 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](#MockingNonVirtualMethods).
|
||||
recipe for [mocking non-virtual methods](#mocking-non-virtual-methods).
|
||||
|
||||
### Old-Style `MOCK_METHODn` Macros
|
||||
|
||||
|
|
@ -337,7 +337,7 @@ Foo, bool(int))` </td> </tr> <tr> <td> New </td> <td> `MOCK_METHOD(bool, Foo,
|
|||
|
||||
</table>
|
||||
|
||||
### The Nice, the Strict, and the Naggy {#NiceStrictNaggy}
|
||||
### The Nice, the Strict, and the Naggy
|
||||
|
||||
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
|
||||
|
|
@ -408,7 +408,7 @@ TEST(...) {
|
|||
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](#uninteresting-vs-unexpected).
|
||||
[Understanding Uninteresting vs Unexpected Calls](#understanding-uninteresting-vs-unexpected-calls).
|
||||
|
||||
There are some caveats though (I dislike them just as much as the next guy, but
|
||||
sadly they are side effects of C++'s limitations):
|
||||
|
|
@ -444,7 +444,7 @@ 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}
|
||||
### Simplifying the Interface without Breaking Existing Code
|
||||
|
||||
Sometimes a method has a long list of arguments that is mostly uninteresting.
|
||||
For example:
|
||||
|
|
@ -578,7 +578,7 @@ 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}
|
||||
### Delegating Calls to a Fake
|
||||
|
||||
Some times you have a non-trivial fake implementation of an interface. For
|
||||
example:
|
||||
|
|
@ -669,7 +669,7 @@ TEST(AbcTest, Xyz) {
|
|||
* 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](#SelectOverload); to disambiguate a fake function (the
|
||||
use [this technique](#selecting-between-overloaded-functions); 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,
|
||||
|
|
@ -707,7 +707,7 @@ 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](#DelegatingToFake)
|
||||
This technique is very similar to the [delegating-to-fake](#delegating-calls-to-a-fake)
|
||||
technique, the difference being that we use a real object instead of a fake.
|
||||
Here's an example:
|
||||
|
||||
|
|
@ -850,7 +850,7 @@ A frequently used matcher is `_`, which matches anything:
|
|||
```
|
||||
<!-- GOOGLETEST_CM0022 DO NOT DELETE -->
|
||||
|
||||
### Combining Matchers {#CombiningMatchers}
|
||||
### Combining Matchers
|
||||
|
||||
You can build complex matchers from existing ones using `AllOf()`,
|
||||
`AllOfArray()`, `AnyOf()`, `AnyOfArray()` and `Not()`:
|
||||
|
|
@ -871,7 +871,7 @@ using ::testing::Not;
|
|||
NULL));
|
||||
```
|
||||
|
||||
### Casting Matchers {#SafeMatcherCast}
|
||||
### Casting Matchers
|
||||
|
||||
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)`
|
||||
|
|
@ -926,7 +926,7 @@ can `static_cast` type `T` to type `U`.
|
|||
always safe as it could throw away information, for example), so be careful not
|
||||
to misuse/abuse it.
|
||||
|
||||
### Selecting Between Overloaded Functions {#SelectOverload}
|
||||
### Selecting Between Overloaded Functions
|
||||
|
||||
If you expect an overloaded function to be called, the compiler may need some
|
||||
help on which overloaded version it is.
|
||||
|
|
@ -1049,7 +1049,7 @@ z`. Note that in this example, it wasn't necessary specify the positional
|
|||
matchers.
|
||||
|
||||
As a convenience and example, gMock provides some matchers for 2-tuples,
|
||||
including the `Lt()` matcher above. See [here](#MultiArgMatchers) for the
|
||||
including the `Lt()` matcher above. See [here](cheat_sheet.md#multi-argument-matchers) for the
|
||||
complete list.
|
||||
|
||||
Note that if you want to pass the arguments to a predicate of your own (e.g.
|
||||
|
|
@ -1145,7 +1145,7 @@ Hamcrest project, which adds `assertThat()` to JUnit.
|
|||
|
||||
### Using Predicates as Matchers
|
||||
|
||||
gMock provides a [built-in set](#MatcherList) of matchers. In case you find them
|
||||
gMock provides a [built-in set](cheat_sheet.md#matchers) of matchers. In case you find them
|
||||
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:
|
||||
|
|
@ -1243,7 +1243,7 @@ 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()`](#CombiningMatchers).
|
||||
that there are [`AllOf()` and `AllOfArray()`](cheat_sheet.md#composite-matchers).
|
||||
|
||||
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
|
||||
|
|
@ -1308,7 +1308,7 @@ to a number less than 3 (what a mouthful...).
|
|||
|
||||
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](#NewMatchers). If you want to do it
|
||||
messages, you should [define a matcher](#writing-new-matchers-quickly). 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
|
||||
|
|
@ -1467,7 +1467,7 @@ using ::testing::Matcher;
|
|||
... use in_range as a matcher in multiple EXPECT_CALLs ...
|
||||
```
|
||||
|
||||
### Matchers must have no side-effects {#PureMatchers}
|
||||
### Matchers must have no side-effects
|
||||
|
||||
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
|
||||
|
|
@ -1481,7 +1481,7 @@ mock object and gMock.
|
|||
|
||||
## Setting Expectations
|
||||
|
||||
### Knowing When to Expect {#UseOnCall}
|
||||
### Knowing When to Expect
|
||||
|
||||
<!-- GOOGLETEST_CM0018 DO NOT DELETE -->
|
||||
|
||||
|
|
@ -1540,7 +1540,7 @@ 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](#DefaultValue)) or `ON_CALL()`.
|
||||
`DefaultValue<T>::Set()` (described [here](#setting-the-default-value-for-a-return-type)) 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
|
||||
|
|
@ -1573,7 +1573,7 @@ using ::testing::Gt;
|
|||
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}
|
||||
### Understanding Uninteresting vs Unexpected Calls
|
||||
|
||||
*Uninteresting* calls and *unexpected* calls are different concepts in gMock.
|
||||
*Very* different.
|
||||
|
|
@ -1646,9 +1646,9 @@ Note that the order of the two `EXPECT_CALL`s 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"](#NiceStrictNaggy).
|
||||
["The Nice, the Strict, and the Naggy"](#the-nice-the-strict-and-the-naggy).
|
||||
|
||||
### Ignoring Uninteresting Arguments {#ParameterlessExpectations}
|
||||
### Ignoring Uninteresting Arguments
|
||||
|
||||
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:
|
||||
|
|
@ -1665,16 +1665,16 @@ or order of calls), you can often simply omit the parameter list:
|
|||
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](#SimplerInterfaces) than the mocked class
|
||||
supplying a [simpler mock interface](#simplifying-the-interface-without-breaking-existing-code) 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](#SaveArgVerify). If
|
||||
SaveArg actions to [save the values for later verification](#verifying-complex-arguments). 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}
|
||||
### Expecting Ordered Calls
|
||||
|
||||
Although an `EXPECT_CALL()` statement defined earlier takes precedence when
|
||||
gMock tries to match a function call with an expectation, by default calls don't
|
||||
|
|
@ -1705,7 +1705,7 @@ In this example, we expect a call to `foo.DoThis(5)`, followed by two calls to
|
|||
a call to `foo.DoThis(6)`. If a call occurred out-of-order, gMock will report an
|
||||
error.
|
||||
|
||||
### Expecting Partially Ordered Calls {#PartialOrder}
|
||||
### Expecting Partially Ordered Calls
|
||||
|
||||
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
|
||||
|
|
@ -1713,7 +1713,7 @@ brittle tests. For example, we may care about `A` occurring before both `B` and
|
|||
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](#AfterClause) clause of
|
||||
calls. One way to express the DAG is to use the [After](cheat_sheet.md#the-after-clause) clause of
|
||||
`EXPECT_CALL`.
|
||||
|
||||
Another way is via the `InSequence()` clause (not the same as the `InSequence`
|
||||
|
|
@ -1922,7 +1922,7 @@ class MockFoo : public Foo {
|
|||
action_n));
|
||||
```
|
||||
|
||||
### Verifying Complex Arguments {#SaveArgVerify}
|
||||
### Verifying Complex Arguments
|
||||
|
||||
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
|
||||
|
|
@ -1946,7 +1946,7 @@ You can instead save the arguments and test them individually:
|
|||
EXPECT_THAT(actual_proto, EqualsProto( ... ));
|
||||
```
|
||||
|
||||
### Mocking Side Effects {#MockingSideEffects}
|
||||
### Mocking Side Effects
|
||||
|
||||
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
|
||||
|
|
@ -2091,7 +2091,7 @@ ACTION_P(ReturnPointee, p) { return *p; }
|
|||
Here `my_mock.GetPrevValue()` will always return the argument of the last
|
||||
`UpdateValue()` call.
|
||||
|
||||
### Setting the Default Value for a Return Type {#DefaultValue}
|
||||
### Setting the Default Value for a Return Type
|
||||
|
||||
If a mock method's return type is a built-in C++ type or pointer, by default it
|
||||
will return 0 when invoked. Also, in C++ 11 and above, a mock method whose
|
||||
|
|
@ -2172,7 +2172,7 @@ Note that both `ON_CALL` and `EXPECT_CALL` have the same "later statements take
|
|||
precedence" rule, but they don't interact. That is, `EXPECT_CALL`s have their
|
||||
own precedence order distinct from the `ON_CALL` precedence order.
|
||||
|
||||
### Using Functions/Methods/Functors/Lambdas as Actions {#FunctionsAsActions}
|
||||
### Using Functions/Methods/Functors/Lambdas as Actions
|
||||
|
||||
If the built-in actions don't suit you, you can use an existing callable
|
||||
(function, `std::function`, method, functor, lambda as an action.
|
||||
|
|
@ -2459,7 +2459,7 @@ class MockFoo : public Foo {
|
|||
Note that you **cannot** use `IgnoreResult()` on an action that already returns
|
||||
`void`. Doing so will lead to ugly compiler errors.
|
||||
|
||||
### Selecting an Action's Arguments {#SelectingArgs}
|
||||
### Selecting an Action's Arguments
|
||||
|
||||
Say you have a mock function `Foo()` that takes seven arguments, and you have a
|
||||
custom action that you want to invoke when `Foo()` is called. Trouble is, the
|
||||
|
|
@ -2545,7 +2545,7 @@ Here are more tips:
|
|||
|
||||
### Ignoring Arguments in Action Functions
|
||||
|
||||
The [selecting-an-action's-arguments](#SelectingArgs) recipe showed us one way
|
||||
The [selecting-an-action's-arguments](#selecting-an-actions-arguments) recipe showed us one way
|
||||
to make a mock function and an action with incompatible argument lists fit
|
||||
together. The downside is that wrapping the action in `WithArgs<...>()` can get
|
||||
tedious for people writing the tests.
|
||||
|
|
@ -2717,7 +2717,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:
|
||||
|
|
@ -2783,7 +2783,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:
|
||||
|
|
@ -2826,7 +2826,7 @@ 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-functionsmethodsfunctorslambdas-as-actions):
|
||||
|
||||
```cpp
|
||||
using ::testing::Unused;
|
||||
|
|
@ -2847,7 +2847,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
|
||||
|
|
@ -2984,7 +2984,7 @@ indicate whether the verification was successful (`true` for yes), so you can
|
|||
wrap that function call inside a `ASSERT_TRUE()` if there is no point going
|
||||
further when the verification has failed.
|
||||
|
||||
### Using Check Points {#UsingCheckPoints}
|
||||
### Using Check Points
|
||||
|
||||
Sometimes you may want to "reset" a mock object at various check points in your
|
||||
test: at each check point, you verify that all existing expectations on the mock
|
||||
|
|
@ -3052,7 +3052,7 @@ easy to tell which `Bar("a")` is called by which call to `Foo()`.
|
|||
|
||||
Sometimes you want to make sure a mock object is destructed at the right time,
|
||||
e.g. after `bar->A()` is called but before `bar->B()` is called. We already know
|
||||
that you can specify constraints on the [order](#OrderedCalls) of mock function
|
||||
that you can specify constraints on the [order](#expecting-ordered-calls) of mock function
|
||||
calls, so all we need to do is to mock the destructor of the mock function.
|
||||
|
||||
This sounds simple, except for one problem: a destructor is a special function
|
||||
|
|
@ -3096,7 +3096,7 @@ testing when its `Die()` method is called:
|
|||
|
||||
And that's that.
|
||||
|
||||
### Using gMock and Threads {#UsingThreads}
|
||||
### Using gMock and Threads
|
||||
|
||||
In a **unit** test, it's best if you could isolate and test a piece of code in a
|
||||
single-threaded context. That avoids race conditions and dead locks, and makes
|
||||
|
|
@ -3295,11 +3295,11 @@ after typing `M-m`), or `M-up`/`M-down` to move back and forth between errors.
|
|||
|
||||
## Extending gMock
|
||||
|
||||
### Writing New Matchers Quickly {#NewMatchers}
|
||||
### Writing New Matchers Quickly
|
||||
|
||||
WARNING: gMock does not guarantee when or how many times a matcher will be
|
||||
invoked. Therefore, all matchers must be functionally pure. See
|
||||
[this section](#PureMatchers) for more details.
|
||||
[this section](#matchers-must-have-no-side-effects) for more details.
|
||||
|
||||
The `MATCHER*` family of macros can be used to define custom matchers easily.
|
||||
The syntax:
|
||||
|
|
@ -3718,7 +3718,7 @@ A cardinality is used in `Times()` to tell gMock how many times you expect a
|
|||
call to occur. It doesn't have to be exact. For example, you can say
|
||||
`AtLeast(5)` or `Between(2, 4)`.
|
||||
|
||||
If the [built-in set](cheat_sheet.md#CardinalityList) of cardinalities doesn't
|
||||
If the [built-in set](cheat_sheet.md#cardinalities) of cardinalities doesn't
|
||||
suit you, you are free to define your own by implementing the following
|
||||
interface (in namespace `testing`):
|
||||
|
||||
|
|
@ -3771,7 +3771,7 @@ Cardinality EvenNumber() {
|
|||
.Times(EvenNumber());
|
||||
```
|
||||
|
||||
### Writing New Actions Quickly {#QuickNewActions}
|
||||
### Writing New Actions Quickly
|
||||
|
||||
If the built-in actions don't work for you, you can easily define your own one.
|
||||
Just define a functor class with a (possibly templated) call operator, matching
|
||||
|
|
@ -4063,7 +4063,7 @@ Note that we have to pick different suffixes (`Action`, `ActionP`, `ActionP2`,
|
|||
and etc) for actions with different numbers of value parameters, or the action
|
||||
definitions cannot be overloaded on the number of them.
|
||||
|
||||
### Writing New Monomorphic Actions {#NewMonoActions}
|
||||
### Writing New Monomorphic Actions
|
||||
|
||||
While the `ACTION*` macros are very convenient, sometimes they are
|
||||
inappropriate. For example, despite the tricks shown in the previous recipes,
|
||||
|
|
@ -4120,7 +4120,7 @@ Action<IncrementMethod> IncrementArgument() {
|
|||
foo.Baz(&n); // Should return 5 and change n to 6.
|
||||
```
|
||||
|
||||
### Writing New Polymorphic Actions {#NewPolyActions}
|
||||
### Writing New Polymorphic Actions
|
||||
|
||||
The previous recipe showed you how to define your own action. This is all good,
|
||||
except that you need to know the type of the function in which the action will
|
||||
|
|
@ -4216,7 +4216,7 @@ particular type than to dump the bytes.
|
|||
<!--#include file="includes/g3_testing_LOGs.md"-->
|
||||
<!--#include file="includes/g3_mock_callbacks.md"-->
|
||||
|
||||
### Mock std::function {#MockFunction}
|
||||
### Mock std::function
|
||||
|
||||
`std::function` is a general function type introduced in C++11. It is a
|
||||
preferred way of passing callbacks to new interfaces. Functions are copiable,
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## gMock for Dummies {#GMockForDummies}
|
||||
## gMock for Dummies
|
||||
|
||||
<!-- GOOGLETEST_CM0013 DO NOT DELETE -->
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ them fast and reliable, using mocks manually in C++ is *hard*:
|
|||
one.
|
||||
|
||||
In contrast, Java and Python programmers have some fine mock frameworks (jMock,
|
||||
EasyMock, [Mox](http://wtf/mox), etc), which automate the creation of mocks. As
|
||||
EasyMock, [Mox](https://code.google.com/archive/p/pymox/wikis/MoxDocumentation.wiki), etc), which automate the creation of mocks. As
|
||||
a result, mocking is a proven effective technique and widely adopted practice in
|
||||
those communities. Having the right tool absolutely makes the difference.
|
||||
|
||||
|
|
@ -148,7 +148,7 @@ follow:
|
|||
|
||||
* Derive a class `MockTurtle` from `Turtle`.
|
||||
* Take a *virtual* function of `Turtle` (while it's possible to
|
||||
[mock non-virtual methods using templates](cook_book.md#MockingNonVirtualMethods),
|
||||
[mock non-virtual methods using templates](cook_book.md#mocking-non-virtual-methods),
|
||||
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
|
||||
|
|
@ -374,8 +374,8 @@ convenient way of saying "any value".
|
|||
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](cook_book.md#NewMatchers)); for example:
|
||||
[built-in matchers](cheat_sheet.md#matchers) for common types (as well as
|
||||
[custom matchers](cook_book.md#writing-new-matchers-quickly)); for example:
|
||||
|
||||
```cpp
|
||||
using ::testing::Ge;
|
||||
|
|
@ -397,7 +397,7 @@ 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](cook_book.md#SelectOverload).
|
||||
[types of the arguments](cook_book.md#selecting-between-overloaded-functions).
|
||||
|
||||
#### Cardinalities: How Many Times Will It Be Called?
|
||||
|
||||
|
|
@ -414,7 +414,7 @@ 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](cheat_sheet.md#CardinalityList).
|
||||
[here](cheat_sheet.md#cardinalities).
|
||||
|
||||
The `Times()` clause can be omitted. **If you omit `Times()`, gMock will infer
|
||||
the cardinality for you.** The rules are easy to remember:
|
||||
|
|
@ -522,7 +522,7 @@ will be taken afterwards. So the right answer is that `turtle.GetY()` will
|
|||
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
|
||||
|
||||
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
|
||||
|
|
@ -561,9 +561,9 @@ 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](cook_book.md#uninteresting-vs-unexpected).
|
||||
[Understanding Uninteresting vs Unexpected Calls](cook_book.md#understanding-uninteresting-vs-unexpected-calls).
|
||||
|
||||
#### Ordered vs Unordered Calls {#OrderedCalls}
|
||||
#### Ordered vs Unordered Calls
|
||||
|
||||
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
|
||||
|
|
@ -598,9 +598,9 @@ order as written. If a call is made out-of-order, it will be an error.
|
|||
|
||||
(What if you care about the relative order of some of the calls, but not all of
|
||||
them? Can you specify an arbitrary partial order? The answer is ... yes! The
|
||||
details can be found [here](cook_book.md#OrderedCalls).)
|
||||
details can be found [here](cook_book.md#expecting-partially-ordered-calls).)
|
||||
|
||||
#### All Expectations Are Sticky (Unless Said Otherwise) {#StickyExpectations}
|
||||
#### All Expectations Are Sticky (Unless Said Otherwise)
|
||||
|
||||
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*
|
||||
|
|
@ -623,7 +623,7 @@ Suppose `turtle.GoTo(0, 0)` is called three times. In the third time, gMock will
|
|||
see that the arguments match expectation #2 (remember that we always pick the
|
||||
last matching expectation). Now, since we said that there should be only two
|
||||
such calls, gMock will report an error immediately. This is basically what we've
|
||||
told you in the [Using Multiple Expectations](#MultiExpectations) section above.
|
||||
told you in the [Using Multiple Expectations](#using-multiple-expectations) section above.
|
||||
|
||||
This example shows that **expectations in gMock are "sticky" by default**, in
|
||||
the sense that they remain active even after we have reached their invocation
|
||||
|
|
@ -697,4 +697,4 @@ For example, in some tests we may not care about how many times `GetX()` and
|
|||
In gMock, if you are not interested in a method, just don't say anything about
|
||||
it. If a call to this method occurs, you'll see a warning in the test output,
|
||||
but it won't be a failure. This is called "naggy" behavior; to change, see
|
||||
[The Nice, the Strict, and the Naggy](cook_book.md#NiceStrictNaggy).
|
||||
[The Nice, the Strict, and the Naggy](cook_book.md#the-nice-the-strict-and-the-naggy).
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
## Legacy gMock FAQ {#GMockFaq}
|
||||
## Legacy gMock FAQ
|
||||
|
||||
<!-- GOOGLETEST_CM0021 DO NOT DELETE -->
|
||||
|
||||
### When I call a method on my mock object, the method for the real object is invoked instead. What's the problem?
|
||||
|
||||
In order for a method to be mocked, it must be *virtual*, unless you use the
|
||||
[high-perf dependency injection technique](#MockingNonVirtualMethods).
|
||||
[high-perf dependency injection technique](cook_book.md#mocking-non-virtual-methods).
|
||||
|
||||
### Can I mock a variadic function?
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ trace, you'll gain insights on why the expectations you set are not met.
|
|||
|
||||
If you see the message "The mock function has no default action set, and its
|
||||
return type has no default value set.", then try
|
||||
[adding a default action](for_dummies.md#DefaultValue). Due to a known issue,
|
||||
[adding a default action](cheat_sheet.md#setting-default-actions). Due to a known issue,
|
||||
unexpected calls on mocks without default actions don't print out a detailed
|
||||
comparison between the actual arguments and the expected arguments.
|
||||
|
||||
|
|
@ -294,9 +294,9 @@ using ::testing::_;
|
|||
|
||||
If you find yourself needing to perform some action that's not supported by
|
||||
gMock directly, remember that you can define your own actions using
|
||||
[`MakeAction()`](#NewMonoActions) or
|
||||
[`MakePolymorphicAction()`](#NewPolyActions), or you can write a stub function
|
||||
and invoke it using [`Invoke()`](#FunctionsAsActions).
|
||||
[`MakeAction()`](cook_book.md#writing-new-monomorphic-actions) or
|
||||
[`MakePolymorphicAction()`](cook_book.md#writing-new-polymorphic-actions), or you can write a stub function
|
||||
and invoke it using [`Invoke()`](cook_book.md#using-functionsmethodsfunctorslambdas-as-actions).
|
||||
|
||||
```cpp
|
||||
using ::testing::_;
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ c is 10
|
|||
>
|
||||
> 1. If you see a compiler error "no matching function to call" when using
|
||||
> `ASSERT_PRED*` or `EXPECT_PRED*`, please see
|
||||
> [this](faq.md#the-compiler-complains-no-matching-function-to-call-when-i-use-assert-pred-how-do-i-fix-it)
|
||||
> [this](faq.md#the-compiler-complains-no-matching-function-to-call-when-i-use-assert_pred-how-do-i-fix-it)
|
||||
> for how to resolve it.
|
||||
|
||||
#### Using a Function That Returns an AssertionResult
|
||||
|
|
@ -397,8 +397,8 @@ in the gMock Cookbook for more details.
|
|||
|
||||
gMock has a rich set of matchers. You can do many things googletest cannot do
|
||||
alone with them. For a list of matchers gMock provides, read
|
||||
[this](../../googlemock/docs/cook_book.md##using-matchers). It's easy to write
|
||||
your [own matchers](../../googlemock/docs/cook_book.md#NewMatchers) too.
|
||||
[this](../../googlemock/docs/cheat_sheet.md#matchers). It's easy to write
|
||||
your [own matchers](../../googlemock/docs/cook_book.md#writing-new-matchers-quickly) too.
|
||||
|
||||
gMock is bundled with googletest, so you don't need to add any build dependency
|
||||
in order to take advantage of this. Just include `"testing/base/public/gmock.h"`
|
||||
|
|
@ -521,7 +521,7 @@ according to the C++ language specification, and so you may not use fatal
|
|||
assertions in them; you'll get a compilation error if you try. Instead, either
|
||||
call `abort` and crash the entire test executable, or put the fatal assertion in
|
||||
a `SetUp`/`TearDown` function; see
|
||||
[constructor/destructor vs. `SetUp`/`TearDown`](faq.md#CtorVsSetUp)
|
||||
[constructor/destructor vs. `SetUp`/`TearDown`](faq.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-setupteardown)
|
||||
|
||||
WARNING: A fatal assertion in a helper function (private void-returning method)
|
||||
called from a constructor or destructor does not does not terminate the current
|
||||
|
|
@ -625,7 +625,7 @@ _death tests_. More generally, any test that checks that a program terminates
|
|||
Note that if a piece of code throws an exception, we don't consider it "death"
|
||||
for the purpose of death tests, as the caller of the code could catch the
|
||||
exception and avoid the crash. If you want to verify exceptions thrown by your
|
||||
code, see [Exception Assertions](#ExceptionAssertions).
|
||||
code, see [Exception Assertions](#exception-assertions).
|
||||
|
||||
If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see
|
||||
Catching Failures
|
||||
|
|
|
|||
|
|
@ -298,7 +298,7 @@ In the end, this boils down to good concurrent programming. You have to make
|
|||
sure that there is no race conditions or dead locks in your program. No silver
|
||||
bullet - sorry!
|
||||
|
||||
## Should I use the constructor/destructor of the test fixture or SetUp()/TearDown()? {#CtorVsSetUp}
|
||||
## Should I use the constructor/destructor of the test fixture or SetUp()/TearDown()?
|
||||
|
||||
The first thing to remember is that googletest does **not** reuse the same test
|
||||
fixture object across multiple tests. For each `TEST_F`, googletest will create
|
||||
|
|
|
|||
|
|
@ -198,11 +198,11 @@ objects, you should use `ASSERT_EQ`.
|
|||
|
||||
When doing pointer comparisons use `*_EQ(ptr, nullptr)` and `*_NE(ptr, nullptr)`
|
||||
instead of `*_EQ(ptr, NULL)` and `*_NE(ptr, NULL)`. This is because `nullptr` is
|
||||
typed, while `NULL` is not. See the [FAQ](faq.md) for more details.
|
||||
typed, while `NULL` is not. See the [FAQ](faq.md#why-does-googletest-support-expect_eqnull-ptr-and-assert_eqnull-ptr-but-not-expect_nenull-ptr-and-assert_nenull-ptr) for more details.
|
||||
|
||||
If you're working with floating point numbers, you may want to use the floating
|
||||
point variations of some of these macros in order to avoid problems caused by
|
||||
rounding. See [Advanced googletest Topics](advanced.md) for details.
|
||||
rounding. See [Advanced googletest Topics](advanced.md#floating-point-comparison) for details.
|
||||
|
||||
Macros in this section work with both narrow and wide string objects (`string`
|
||||
and `wstring`).
|
||||
|
|
@ -238,7 +238,7 @@ of two wide strings fails, their values will be printed as UTF-8 narrow strings.
|
|||
**Availability**: Linux, Windows, Mac.
|
||||
|
||||
**See also**: For more string comparison tricks (substring, prefix, suffix, and
|
||||
regular expression matching, for example), see [this](advanced.md) in the
|
||||
regular expression matching, for example), see [this](advanced.md#more-string-assertions) in the
|
||||
Advanced googletest Guide.
|
||||
|
||||
## Simple Tests
|
||||
|
|
@ -301,7 +301,7 @@ for
|
|||
|
||||
**Availability**: Linux, Windows, Mac.
|
||||
|
||||
## Test Fixtures: Using the Same Data Configuration for Multiple Tests {#same-data-multiple-tests}
|
||||
## Test Fixtures: Using the Same Data Configuration for Multiple Tests
|
||||
|
||||
If you find yourself writing two or more tests that operate on similar data, you
|
||||
can use a *test fixture*. This allows you to reuse the same configuration of
|
||||
|
|
@ -319,7 +319,7 @@ To create a fixture:
|
|||
4. If necessary, write a destructor or `TearDown()` function to release any
|
||||
resources you allocated in `SetUp()` . To learn when you should use the
|
||||
constructor/destructor and when you should use `SetUp()/TearDown()`, read
|
||||
the [FAQ](faq.md#CtorVsSetUp).
|
||||
the [FAQ](faq.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-setupteardown).
|
||||
5. If needed, define subroutines for your tests to share.
|
||||
|
||||
When using a fixture, use `TEST_F()` instead of `TEST()` as it allows you to
|
||||
|
|
@ -543,7 +543,7 @@ int main(int argc, char **argv) {
|
|||
The `::testing::InitGoogleTest()` function parses the command line for
|
||||
googletest flags, and removes all recognized flags. This allows the user to
|
||||
control a test program's behavior via various flags, which we'll cover in
|
||||
the [AdvancedGuide](advanced.md). You **must** call this function before calling
|
||||
the [AdvancedGuide](advanced.md#running-test-programs-advanced-options). You **must** call this function before calling
|
||||
`RUN_ALL_TESTS()`, or the flags won't be properly initialized.
|
||||
|
||||
On Windows, `InitGoogleTest()` also works with wide strings, so it can be used
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Googletest Samples {#samples}
|
||||
# Googletest Samples
|
||||
|
||||
If you're like us, you'd like to look at
|
||||
[googletest samples.](https://github.com/google/googletest/tree/master/googletest/samples)
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user