diff options
Diffstat (limited to 'googlemock')
| -rw-r--r-- | googlemock/CHANGES | 2 | ||||
| -rw-r--r-- | googlemock/README.md | 39 | ||||
| -rw-r--r-- | googlemock/configure.ac | 2 | ||||
| -rw-r--r-- | googlemock/docs/CookBook.md | 30 | ||||
| -rw-r--r-- | googlemock/docs/DevGuide.md | 2 | ||||
| -rw-r--r-- | googlemock/docs/ForDummies.md | 2 | ||||
| -rw-r--r-- | googlemock/docs/v1_5/CookBook.md | 17 | ||||
| -rw-r--r-- | googlemock/docs/v1_6/CookBook.md | 17 | ||||
| -rw-r--r-- | googlemock/docs/v1_7/CookBook.md | 17 | ||||
| -rw-r--r-- | googlemock/src/gmock-matchers.cc | 2 | ||||
| -rw-r--r-- | googlemock/test/gmock-generated-actions_test.cc | 2 |
11 files changed, 89 insertions, 43 deletions
diff --git a/googlemock/CHANGES b/googlemock/CHANGES index d6f2f76..4328ece 100644 --- a/googlemock/CHANGES +++ b/googlemock/CHANGES @@ -94,7 +94,7 @@ Google Test): * New feature: --gmock_catch_leaked_mocks for detecting leaked mocks. * New feature: ACTION_TEMPLATE for defining templatized actions. * New feature: the .After() clause for specifying expectation order. - * New feature: the .With() clause for for specifying inter-argument + * New feature: the .With() clause for specifying inter-argument constraints. * New feature: actions ReturnArg<k>(), ReturnNew<T>(...), and DeleteArg<k>(). diff --git a/googlemock/README.md b/googlemock/README.md index 7b13a6d..7efc068 100644 --- a/googlemock/README.md +++ b/googlemock/README.md @@ -125,13 +125,46 @@ build Google Mock and its tests, which has further requirements: ### Building Google Mock ### +#### Using CMake #### + If you have CMake available, it is recommended that you follow the [build instructions][gtest_cmakebuild] -as described for Google Test. If are using Google Mock with an +as described for Google Test. + +If are using Google Mock with an existing CMake project, the section [Incorporating Into An Existing CMake Project][gtest_incorpcmake] -may be of particular interest. Otherwise, the following sections -detail how to build Google Mock without CMake. +may be of particular interest. +To make it work for Google Mock you will need to change + + target_link_libraries(example gtest_main) + +to + + target_link_libraries(example gmock_main) + +This works because `gmock_main` library is compiled with Google Test. +However, it does not automatically add Google Test includes. +Therefore you will also have to change + + if (CMAKE_VERSION VERSION_LESS 2.8.11) + include_directories("${gtest_SOURCE_DIR}/include") + endif() + +to + + if (CMAKE_VERSION VERSION_LESS 2.8.11) + include_directories(BEFORE SYSTEM + "${gtest_SOURCE_DIR}/include" "${gmock_SOURCE_DIR}/include") + else() + target_include_directories(gmock_main SYSTEM BEFORE INTERFACE + "${gtest_SOURCE_DIR}/include" "${gmock_SOURCE_DIR}/include") + endif() + +This will addtionally mark Google Mock includes as system, which will +silence compiler warnings when compiling your tests using clang with +`-Wpedantic -Wall -Wextra -Wconversion`. + #### Preparing to Build (Unix only) #### diff --git a/googlemock/configure.ac b/googlemock/configure.ac index 3b740f2..edfd896 100644 --- a/googlemock/configure.ac +++ b/googlemock/configure.ac @@ -130,7 +130,7 @@ AS_IF([test "x${HAVE_BUILT_GTEST}" = "xyes"], GTEST_LIBS=`${GTEST_CONFIG} --libs` GTEST_VERSION=`${GTEST_CONFIG} --version`], [AC_CONFIG_SUBDIRS([../googletest]) - # GTEST_CONFIG needs to be executable both in a Makefile environmont and + # GTEST_CONFIG needs to be executable both in a Makefile environment and # in a shell script environment, so resolve an absolute path for it here. GTEST_CONFIG="`pwd -P`/../googletest/scripts/gtest-config" GTEST_CPPFLAGS='-I$(top_srcdir)/../googletest/include' diff --git a/googlemock/docs/CookBook.md b/googlemock/docs/CookBook.md index 0460d35..3d2ae4a 100644 --- a/googlemock/docs/CookBook.md +++ b/googlemock/docs/CookBook.md @@ -18,8 +18,9 @@ You must always put a mock method definition (`MOCK_METHOD*`) in a `public:` section of the mock class, regardless of the method being mocked being `public`, `protected`, or `private` in the base class. This allows `ON_CALL` and `EXPECT_CALL` to reference the mock function -from outside of the mock class. (Yes, C++ allows a subclass to change -the access level of a virtual function in the base class.) Example: +from outside of the mock class. (Yes, C++ allows a subclass to specify +a different access level than the base class on a virtual function.) +Example: ``` class Foo { @@ -294,7 +295,7 @@ There are some caveats though (I don't like them just as much as the next guy, but sadly they are side effects of C++'s limitations): 1. `NiceMock<MockFoo>` and `StrictMock<MockFoo>` only work for mock methods defined using the `MOCK_METHOD*` family of macros **directly** in the `MockFoo` class. If a mock method is defined in a **base class** of `MockFoo`, the "nice" or "strict" modifier may not affect it, depending on the compiler. In particular, nesting `NiceMock` and `StrictMock` (e.g. `NiceMock<StrictMock<MockFoo> >`) is **not** supported. - 1. The constructors of the base mock (`MockFoo`) cannot have arguments passed by non-const reference, which happens to be banned by the [Google C++ style guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml). + 1. The constructors of the base mock (`MockFoo`) cannot have arguments passed by non-const reference, which happens to be banned by the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html). 1. During the constructor or destructor of `MockFoo`, the mock object is _not_ nice or strict. This may cause surprises if the constructor or destructor calls a mock method on `this` object. (This behavior, however, is consistent with C++'s general rule: if a constructor or destructor calls a virtual method of `this` object, that method is treated as non-virtual. In other words, to the base class's constructor or destructor, `this` object behaves like an instance of the base class, not the derived class. This rule is required for safety. Otherwise a base constructor may use members of a derived class before they are initialized, or a base destructor may use members of a derived class after they have been destroyed.) Finally, you should be **very cautious** about when to use naggy or strict mocks, as they tend to make tests more brittle and harder to maintain. When you refactor your code without changing its externally visible behavior, ideally you should't need to update any tests. If your code interacts with a naggy mock, however, you may start to get spammed with warnings as the result of your change. Worse, if your code interacts with a strict mock, your tests may start to fail and you'll be forced to fix them. Our general recommendation is to use 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. @@ -1029,9 +1030,10 @@ a value that satisfies matcher `m`. For example: -> | `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. | +| Expression | Description | |:-----------------------------|:-----------------------------------| -> | `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. | +| `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. | +| `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. | Note that in `Property(&Foo::baz, ...)`, method `baz()` must take no argument and be declared as `const`. @@ -1919,9 +1921,9 @@ using ::testing::_; // second argument DoThis() receives. ``` -Arghh, you need to refer to a mock function argument but C++ has no -lambda (yet), so you have to define your own action. :-( Or do you -really? +Arghh, you need to refer to a mock function argument but your version +of C++ has no lambdas, so you have to define your own action. :-( +Or do you really? Well, Google Mock has an action to solve _exactly_ this problem: @@ -2365,7 +2367,7 @@ Now there’s one topic we haven’t covered: how do you set expectations on `Sh // When one calls ShareBuzz() on the MockBuzzer like this, the call is // forwarded to DoShareBuzz(), which is mocked. Therefore this statement // will trigger the above EXPECT_CALL. - mock_buzzer_.ShareBuzz(MakeUnique<Buzz>(AccessLevel::kInternal), + mock_buzzer_.ShareBuzz(MakeUnique<Buzz>(AccessLevel::kInternal), ::base::Now()); ``` @@ -2404,7 +2406,7 @@ Now, the mock `DoShareBuzz()` method is free to save the buzz argument for later ``` std::unique_ptr<Buzz> intercepted_buzz; EXPECT_CALL(mock_buzzer_, DoShareBuzz(NotNull(), _)) - .WillOnce(Invoke([&intercepted_buzz](Buzz* buzz, Time timestamp) { + .WillOnce(Invoke([&intercepted_buzz](Buzz* buzz, Time timestamp) { // Save buzz in intercepted_buzz for analysis later. intercepted_buzz.reset(buzz); return false; @@ -2482,12 +2484,12 @@ MockFoo::~MockFoo() {} ## Forcing a Verification ## -When it's being destoyed, your friendly mock object will automatically +When it's being destroyed, your friendly mock object will automatically verify that all expectations on it have been satisfied, and will generate [Google Test](../../googletest/) failures if not. This is convenient as it leaves you with one less thing to worry about. That is, unless you are not sure if your mock object will -be destoyed. +be destroyed. How could it be that your mock object won't eventually be destroyed? Well, it might be created on the heap and owned by the code you are @@ -3347,6 +3349,7 @@ For example, when using an `ACTION` as a stub action for mock function: int DoSomething(bool flag, int* ptr); ``` we have: + | **Pre-defined Symbol** | **Is Bound To** | |:-----------------------|:----------------| | `arg0` | the value of `flag` | @@ -3508,6 +3511,7 @@ is asked to infer the type of `x`? If you are writing a function that returns an `ACTION` object, you'll need to know its type. The type depends on the macro used to define the action and the parameter types. The rule is relatively simple: + | **Given Definition** | **Expression** | **Has Type** | |:---------------------|:---------------|:-------------| | `ACTION(Foo)` | `Foo()` | `FooAction` | @@ -3515,7 +3519,7 @@ the action and the parameter types. The rule is relatively simple: | `ACTION_P(Bar, param)` | `Bar(int_value)` | `BarActionP<int>` | | `ACTION_TEMPLATE(Bar, HAS_m_TEMPLATE_PARAMS(...), AND_1_VALUE_PARAMS(p1))` | `Bar<t1, ..., t_m>(int_value)` | `FooActionP<t1, ..., t_m, int>` | | `ACTION_P2(Baz, p1, p2)` | `Baz(bool_value, int_value)` | `BazActionP2<bool, int>` | -| `ACTION_TEMPLATE(Baz, HAS_m_TEMPLATE_PARAMS(...), AND_2_VALUE_PARAMS(p1, p2))` | `Baz<t1, ..., t_m>(bool_value, int_value)` | `FooActionP2<t1, ..., t_m, bool, int>` | +| `ACTION_TEMPLATE(Baz, HAS_m_TEMPLATE_PARAMS(...), AND_2_VALUE_PARAMS(p1, p2))`| `Baz<t1, ..., t_m>(bool_value, int_value)` | `FooActionP2<t1, ..., t_m, bool, int>` | | ... | ... | ... | Note that we have to pick different suffixes (`Action`, `ActionP`, diff --git a/googlemock/docs/DevGuide.md b/googlemock/docs/DevGuide.md index f4bab75..adb74fe 100644 --- a/googlemock/docs/DevGuide.md +++ b/googlemock/docs/DevGuide.md @@ -91,7 +91,7 @@ instructions for how to sign and return it. To keep the source consistent, readable, diffable and easy to merge, we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project. All patches will be expected -to conform to the style outlined [here](https://github.com/google/styleguide/blob/gh-pages/cppguide.xml). +to conform to the style outlined [here](https://google.github.io/styleguide/cppguide.html). ## Submitting Patches ## diff --git a/googlemock/docs/ForDummies.md b/googlemock/docs/ForDummies.md index 0da4cbe..892f1be 100644 --- a/googlemock/docs/ForDummies.md +++ b/googlemock/docs/ForDummies.md @@ -365,7 +365,7 @@ By creating an object of type `InSequence`, all expectations in its scope are pu In this example, we test that `Foo()` calls the three expected functions in the 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! If you are impatient, the details can be found in the [CookBook](CookBook#Expecting_Partially_Ordered_Calls.md).) +(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! If you are impatient, the details can be found in the [CookBook](CookBook.md#expecting-partially-ordered-calls).) ## 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_ (you want to ignore any other instructions it receives)? diff --git a/googlemock/docs/v1_5/CookBook.md b/googlemock/docs/v1_5/CookBook.md index 26e153c..55824bb 100644 --- a/googlemock/docs/v1_5/CookBook.md +++ b/googlemock/docs/v1_5/CookBook.md @@ -1032,9 +1032,10 @@ a value that satisfies matcher `m`. For example: -> | `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. | +| Expression | Description | |:-----------------------------|:-----------------------------------| -> | `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. | +| `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. | +| `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. | Note that in `Property(&Foo::baz, ...)`, method `baz()` must take no argument and be declared as `const`. @@ -1772,9 +1773,9 @@ using ::testing::_; // second argument DoThis() receives. ``` -Arghh, you need to refer to a mock function argument but C++ has no -lambda (yet), so you have to define your own action. :-( Or do you -really? +Arghh, you need to refer to a mock function argument but your version +of C++ has no lambdas, so you have to define your own action. :-( +Or do you really? Well, Google Mock has an action to solve _exactly_ this problem: @@ -2080,12 +2081,12 @@ versus ## Forcing a Verification ## -When it's being destoyed, your friendly mock object will automatically +When it's being destroyed, your friendly mock object will automatically verify that all expectations on it have been satisfied, and will generate [Google Test](http://code.google.com/p/googletest/) failures if not. This is convenient as it leaves you with one less thing to worry about. That is, unless you are not sure if your mock object will -be destoyed. +be destroyed. How could it be that your mock object won't eventually be destroyed? Well, it might be created on the heap and owned by the code you are @@ -2863,6 +2864,7 @@ For example, when using an `ACTION` as a stub action for mock function: int DoSomething(bool flag, int* ptr); ``` we have: + | **Pre-defined Symbol** | **Is Bound To** | |:-----------------------|:----------------| | `arg0` | the value of `flag` | @@ -3024,6 +3026,7 @@ is asked to infer the type of `x`? If you are writing a function that returns an `ACTION` object, you'll need to know its type. The type depends on the macro used to define the action and the parameter types. The rule is relatively simple: + | **Given Definition** | **Expression** | **Has Type** | |:---------------------|:---------------|:-------------| | `ACTION(Foo)` | `Foo()` | `FooAction` | diff --git a/googlemock/docs/v1_6/CookBook.md b/googlemock/docs/v1_6/CookBook.md index f5975a0..e77a781 100644 --- a/googlemock/docs/v1_6/CookBook.md +++ b/googlemock/docs/v1_6/CookBook.md @@ -1037,9 +1037,10 @@ a value that satisfies matcher `m`. For example: -> | `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. | +| Expression | Description | |:-----------------------------|:-----------------------------------| -> | `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. | +| `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. | +| `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. | Note that in `Property(&Foo::baz, ...)`, method `baz()` must take no argument and be declared as `const`. @@ -1840,9 +1841,9 @@ using ::testing::_; // second argument DoThis() receives. ``` -Arghh, you need to refer to a mock function argument but C++ has no -lambda (yet), so you have to define your own action. :-( Or do you -really? +Arghh, you need to refer to a mock function argument but your version +of C++ has no lambdas, so you have to define your own action. :-( +Or do you really? Well, Google Mock has an action to solve _exactly_ this problem: @@ -2211,12 +2212,12 @@ MockFoo::~MockFoo() {} ## Forcing a Verification ## -When it's being destoyed, your friendly mock object will automatically +When it's being destroyed, your friendly mock object will automatically verify that all expectations on it have been satisfied, and will generate [Google Test](http://code.google.com/p/googletest/) failures if not. This is convenient as it leaves you with one less thing to worry about. That is, unless you are not sure if your mock object will -be destoyed. +be destroyed. How could it be that your mock object won't eventually be destroyed? Well, it might be created on the heap and owned by the code you are @@ -3014,6 +3015,7 @@ For example, when using an `ACTION` as a stub action for mock function: int DoSomething(bool flag, int* ptr); ``` we have: + | **Pre-defined Symbol** | **Is Bound To** | |:-----------------------|:----------------| | `arg0` | the value of `flag` | @@ -3175,6 +3177,7 @@ is asked to infer the type of `x`? If you are writing a function that returns an `ACTION` object, you'll need to know its type. The type depends on the macro used to define the action and the parameter types. The rule is relatively simple: + | **Given Definition** | **Expression** | **Has Type** | |:---------------------|:---------------|:-------------| | `ACTION(Foo)` | `Foo()` | `FooAction` | diff --git a/googlemock/docs/v1_7/CookBook.md b/googlemock/docs/v1_7/CookBook.md index 419a001..0399489 100644 --- a/googlemock/docs/v1_7/CookBook.md +++ b/googlemock/docs/v1_7/CookBook.md @@ -1030,9 +1030,10 @@ a value that satisfies matcher `m`. For example: -> | `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. | +| Expression | Description | |:-----------------------------|:-----------------------------------| -> | `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. | +| `Field(&Foo::number, Ge(3))` | Matches `x` where `x.number >= 3`. | +| `Property(&Foo::name, StartsWith("John "))` | Matches `x` where `x.name()` starts with `"John "`. | Note that in `Property(&Foo::baz, ...)`, method `baz()` must take no argument and be declared as `const`. @@ -1868,9 +1869,9 @@ using ::testing::_; // second argument DoThis() receives. ``` -Arghh, you need to refer to a mock function argument but C++ has no -lambda (yet), so you have to define your own action. :-( Or do you -really? +Arghh, you need to refer to a mock function argument but your version +of C++ has no lambdas, so you have to define your own action. :-( +Or do you really? Well, Google Mock has an action to solve _exactly_ this problem: @@ -2239,12 +2240,12 @@ MockFoo::~MockFoo() {} ## Forcing a Verification ## -When it's being destoyed, your friendly mock object will automatically +When it's being destroyed, your friendly mock object will automatically verify that all expectations on it have been satisfied, and will generate [Google Test](http://code.google.com/p/googletest/) failures if not. This is convenient as it leaves you with one less thing to worry about. That is, unless you are not sure if your mock object will -be destoyed. +be destroyed. How could it be that your mock object won't eventually be destroyed? Well, it might be created on the heap and owned by the code you are @@ -3104,6 +3105,7 @@ For example, when using an `ACTION` as a stub action for mock function: int DoSomething(bool flag, int* ptr); ``` we have: + | **Pre-defined Symbol** | **Is Bound To** | |:-----------------------|:----------------| | `arg0` | the value of `flag` | @@ -3265,6 +3267,7 @@ is asked to infer the type of `x`? If you are writing a function that returns an `ACTION` object, you'll need to know its type. The type depends on the macro used to define the action and the parameter types. The rule is relatively simple: + | **Given Definition** | **Expression** | **Has Type** | |:---------------------|:---------------|:-------------| | `ACTION(Foo)` | `Foo()` | `FooAction` | diff --git a/googlemock/src/gmock-matchers.cc b/googlemock/src/gmock-matchers.cc index e0de25c..6e40e5e 100644 --- a/googlemock/src/gmock-matchers.cc +++ b/googlemock/src/gmock-matchers.cc @@ -288,7 +288,7 @@ class MaxBipartiteMatchState { // Each element of the left_ vector represents a left hand side node // (i.e. an element) and each element of right_ is a right hand side // node (i.e. a matcher). The values in the left_ vector indicate - // outflow from that node to a node on the the right_ side. The values + // outflow from that node to a node on the right_ side. The values // in the right_ indicate inflow, and specify which left_ node is // feeding that right_ node, if any. For example, left_[3] == 1 means // there's a flow from element #3 to matcher #1. Such a flow would also diff --git a/googlemock/test/gmock-generated-actions_test.cc b/googlemock/test/gmock-generated-actions_test.cc index 58d4572..80bcb31 100644 --- a/googlemock/test/gmock-generated-actions_test.cc +++ b/googlemock/test/gmock-generated-actions_test.cc @@ -1120,7 +1120,7 @@ TEST(ActionTemplateTest, WorksForIntegralTemplateParams) { EXPECT_FALSE(b); // Verifies that resetter is deleted. } -// Tests that ACTION_TEMPLATES works for template template parameters. +// Tests that ACTION_TEMPLATE works for a template with template parameters. ACTION_TEMPLATE(ReturnSmartPointer, HAS_1_TEMPLATE_PARAMS(template <typename Pointee> class, Pointer), |