MOCK_CONST_METHOD2_WITH_CALLTYPE(STDMETHODCALLTYPE, Bar, int(double x, double y));
MOCK_CONST_METHOD2_WITH_CALLTYPE(STDMETHODCALLTYPE, Bar, int(double x, double y));
```
```
where `STDMETHODCALLTYPE` is defined by `<objbase.h>` on Windows.
where `STDMETHODCALLTYPE` is defined by `<objbase.h>` on Windows.
...
@@ -249,7 +249,7 @@ match them more flexibly, or get more informative messages, you can use:
...
@@ -249,7 +249,7 @@ match them more flexibly, or get more informative messages, you can use:
| `SizeIs(m)` | `argument` is a container whose size matches `m`. E.g. `SizeIs(2)` or `SizeIs(Lt(2))`. |
| `SizeIs(m)` | `argument` is a container whose size matches `m`. E.g. `SizeIs(2)` or `SizeIs(Lt(2))`. |
| `UnorderedElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, and under some permutation each element matches an `ei` (for a different `i`), which can be a value or a matcher. 0 to 10 arguments are allowed. |
| `UnorderedElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, and under some permutation each element matches an `ei` (for a different `i`), which can be a value or a matcher. 0 to 10 arguments are allowed. |
| `UnorderedElementsAreArray({ e0, e1, ..., en })`, `UnorderedElementsAreArray(array)`, or `UnorderedElementsAreArray(array, count)` | The same as `UnorderedElementsAre()` except that the expected element values/matchers come from an initializer list, STL-style container, or C-style array. |
| `UnorderedElementsAreArray({ e0, e1, ..., en })`, `UnorderedElementsAreArray(array)`, or `UnorderedElementsAreArray(array, count)` | The same as `UnorderedElementsAre()` except that the expected element values/matchers come from an initializer list, STL-style container, or C-style array. |
| `WhenSorted(m)` | When `argument` is sorted using the `<` operator, it matches container matcher `m`. E.g. `WhenSorted(UnorderedElementsAre(1, 2, 3))` verifies that `argument` contains elements `1`, `2`, and `3`, ignoring order. |
| `WhenSorted(m)` | When `argument` is sorted using the `<` operator, it matches container matcher `m`. E.g. `WhenSorted(ElementsAre(1, 2, 3))` verifies that `argument` contains elements `1`, `2`, and `3`, ignoring order. |
| `WhenSortedBy(comparator, m)` | The same as `WhenSorted(m)`, except that the given comparator instead of `<` is used to sort `argument`. E.g. `WhenSortedBy(std::greater<int>(), ElementsAre(3, 2, 1))`. |
| `WhenSortedBy(comparator, m)` | The same as `WhenSorted(m)`, except that the given comparator instead of `<` is used to sort `argument`. E.g. `WhenSortedBy(std::greater<int>(), ElementsAre(3, 2, 1))`. |
@@ -148,7 +148,7 @@ Note that the mock class doesn't define `AppendPacket()`, unlike the
...
@@ -148,7 +148,7 @@ 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.
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
Next, you need a way to say that you want to use
`ConcretePacketStream` in production code, and use `MockPacketStream`
`ConcretePacketStream` in production code and to use `MockPacketStream`
in tests. Since the functions are not virtual and the two classes are
in tests. Since the functions are not virtual and the two classes are
unrelated, you must specify your choice at _compile time_ (as opposed
unrelated, you must specify your choice at _compile time_ (as opposed
to run time).
to run time).
...
@@ -227,7 +227,7 @@ If a mock method has no `EXPECT_CALL` spec but is called, Google Mock
...
@@ -227,7 +227,7 @@ If a mock method has no `EXPECT_CALL` spec but is called, Google Mock
will print a warning about the "uninteresting call". The rationale is:
will print a warning about the "uninteresting call". The rationale is:
* New methods may be added to an interface after a test is written. We shouldn't fail a test just because a method it doesn't know about is called.
* New methods may be added to an interface after a test is written. We shouldn't fail a test just because a method it doesn't know about is called.
* However, this may also mean there's a bug in the test, so Google Mock shouldn't be silent either. If the user believes these calls are harmless, he can add an `EXPECT_CALL()` to suppress the warning.
* However, this may also mean there's a bug in the test, so Google Mock shouldn't be silent either. If the user believes these calls are harmless, they can add an `EXPECT_CALL()` to suppress the warning.
However, sometimes you may want to suppress all "uninteresting call"
However, sometimes you may want to suppress all "uninteresting call"
warnings, while sometimes you may want the opposite, i.e. to treat all
warnings, while sometimes you may want the opposite, i.e. to treat all
...
@@ -706,7 +706,7 @@ type `m` accepts):
...
@@ -706,7 +706,7 @@ type `m` accepts):
1. 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
1. 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
1. 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).
1. 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.
The code won't compile if any of these conditions aren't met.
@@ -64,7 +64,7 @@ compile it in the [README](../README.md) file.
...
@@ -64,7 +64,7 @@ compile it in the [README](../README.md) file.
A mocking framework is of no good if itself is not thoroughly tested.
A mocking framework is of no good if itself is not thoroughly tested.
Tests should be written for any new code, and changes should be
Tests should be written for any new code, and changes should be
verified to not break existing tests before they are submitted for
verified to not break existing tests before they are submitted for
review. To perform the tests, follow the instructions in [README](http://code.google.com/p/googlemock/source/browse/trunk/README) and
review. To perform the tests, follow the instructions in [README](../README.md) and
verify that there are no failures.
verify that there are no failures.
# Contributing Code #
# Contributing Code #
...
@@ -98,7 +98,7 @@ to conform to the style outlined [here](https://google.github.io/styleguide/cppg
...
@@ -98,7 +98,7 @@ to conform to the style outlined [here](https://google.github.io/styleguide/cppg
Please do submit code. Here's what you need to do:
Please do submit code. Here's what you need to do:
1. Normally you should make your change against the SVN trunk instead of a branch or a tag, as the latter two are for release control and should be treated mostly as read-only.
1. Normally you should make your change against the SVN trunk instead of a branch or a tag, as the latter two are for release control and should be treated mostly as read-only.
1. Decide which code you want to submit. A submission should be a set of changes that addresses one issue in the [Google Mock issue tracker](http://code.google.com/p/googlemock/issues/list). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
1. Decide which code you want to submit. A submission should be a set of changes that addresses one issue in the [Google Mock issue tracker](https://github.com/google/googletest/issues). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches.
1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches.
1. Ensure that your code adheres to the [Google Mock source code style](#Coding_Style.md).
1. Ensure that your code adheres to the [Google Mock source code style](#Coding_Style.md).
1. Ensure that there are unit tests for your code.
1. Ensure that there are unit tests for your code.
A list of built-in matchers can be found in the [CheatSheet](CheatSheet.md). For example, here's the `Ge` (greater than or equal) matcher:
A list of built-in matchers can be found in the [CheatSheet](CheatSheet.md). For example, here's the `Ge` (greater than or equal) matcher:
```
```
using ::testing::Ge;...
using ::testing::Ge;
...
EXPECT_CALL(turtle, Forward(Ge(100)));
EXPECT_CALL(turtle, Forward(Ge(100)));
```
```
...
@@ -280,7 +282,8 @@ First, if the return type of a mock function is a built-in type or a pointer, th
...
@@ -280,7 +282,8 @@ First, if the return type of a mock function is a built-in type or a pointer, th
Second, if a mock function doesn't have a default action, or the default action doesn't suit you, you can specify the action to be taken each time the expectation matches using a series of `WillOnce()` clauses followed by an optional `WillRepeatedly()`. For example,
Second, if a mock function doesn't have a default action, or the default action doesn't suit you, you can specify the action to be taken each time the expectation matches using a series of `WillOnce()` clauses followed by an optional `WillRepeatedly()`. For example,
```
```
using ::testing::Return;...
using ::testing::Return;
...
EXPECT_CALL(turtle, GetX())
EXPECT_CALL(turtle, GetX())
.WillOnce(Return(100))
.WillOnce(Return(100))
.WillOnce(Return(200))
.WillOnce(Return(200))
...
@@ -290,7 +293,8 @@ EXPECT_CALL(turtle, GetX())
...
@@ -290,7 +293,8 @@ EXPECT_CALL(turtle, GetX())
This says that `turtle.GetX()` will be called _exactly three times_ (Google Mock inferred this from how many `WillOnce()` clauses we've written, since we didn't explicitly write `Times()`), and will return 100, 200, and 300 respectively.
This says that `turtle.GetX()` will be called _exactly three times_ (Google Mock inferred this from how many `WillOnce()` clauses we've written, since we didn't explicitly write `Times()`), and will return 100, 200, and 300 respectively.
```
```
using ::testing::Return;...
using ::testing::Return;
...
EXPECT_CALL(turtle, GetY())
EXPECT_CALL(turtle, GetY())
.WillOnce(Return(100))
.WillOnce(Return(100))
.WillOnce(Return(200))
.WillOnce(Return(200))
...
@@ -317,7 +321,8 @@ Instead of returning 100, 101, 102, ..., consecutively, this mock function will
...
@@ -317,7 +321,8 @@ Instead of returning 100, 101, 102, ..., consecutively, this mock function will
Time for another quiz! What do you think the following means?
Time for another quiz! What do you think the following means?
```
```
using ::testing::Return;...
using ::testing::Return;
...
EXPECT_CALL(turtle, GetY())
EXPECT_CALL(turtle, GetY())
.Times(4)
.Times(4)
.WillOnce(Return(100));
.WillOnce(Return(100));
...
@@ -331,7 +336,8 @@ So far we've only shown examples where you have a single expectation. More reali
...
@@ -331,7 +336,8 @@ So far we've only shown examples where you have a single expectation. More reali
By default, when a mock method is invoked, Google Mock will search the expectations in the **reverse order** they are defined, and stop when an active expectation that matches the arguments is found (you can think of it as "newer rules override older ones."). If the matching expectation cannot take any more calls, you will get an upper-bound-violated failure. Here's an example:
By default, when a mock method is invoked, Google Mock will search the expectations in the **reverse order** they are defined, and stop when an active expectation that matches the arguments is found (you can think of it as "newer rules override older ones."). If the matching expectation cannot take any more calls, you will get an upper-bound-violated failure. Here's an example:
```
```
using ::testing::_;...
using ::testing::_;
...
EXPECT_CALL(turtle, Forward(_)); // #1
EXPECT_CALL(turtle, Forward(_)); // #1
EXPECT_CALL(turtle, Forward(10)) // #2
EXPECT_CALL(turtle, Forward(10)) // #2
.Times(2);
.Times(2);
...
@@ -347,7 +353,8 @@ By default, an expectation can match a call even though an earlier expectation h
...
@@ -347,7 +353,8 @@ By default, an expectation can match a call even though an earlier expectation h
Sometimes, you may want all the expected calls to occur in a strict order. To say this in Google Mock is easy:
Sometimes, you may want all the expected calls to occur in a strict order. To say this in Google Mock is easy:
```
```
using ::testing::InSequence;...
using ::testing::InSequence;
...
TEST(FooTest, DrawsLineSegment) {
TEST(FooTest, DrawsLineSegment) {
...
...
{
{
...
@@ -373,7 +380,8 @@ Now let's do a quick quiz to see how well you can use this mock stuff already. H
...
@@ -373,7 +380,8 @@ Now let's do a quick quiz to see how well you can use this mock stuff already. H
After you've come up with your answer, take a look at ours and compare notes (solve it yourself first - don't cheat!):
After you've come up with your answer, take a look at ours and compare notes (solve it yourself first - don't cheat!):
