Lines Matching refs:mock
85 You must always put a mock method definition (`MOCK_METHOD`) in a `public:`
86 section of the mock class, regardless of the method being mocked being `public`,
88 `EXPECT_CALL` to reference the mock function from outside of the mock class.
119 You can mock overloaded functions as usual. No special attention is required:
148 **Note:** if you don't mock all versions of the overloaded method, the compiler
157 // We don't want to mock int Add(int times, Element x);
164 You can mock class templates just like any class.
187 gMock can mock non-virtual functions to be used in Hi-perf dependency injection.
190 mock class will be *unrelated* to the real class, but contain methods with the
204 // A mock packet stream class. It inherits from no other, but defines
214 Note that the mock class doesn't define `AppendPacket()`, unlike the real class.
254 It is not possible to directly mock a free function (i.e. a C-style function or
277 Your code should talk to `FileInterface` to open a file. Now it's easy to mock
290 [MockFunction](#MockFunction) to mock the std::function.
396 If a mock method has no `EXPECT_CALL` spec but is called, we say that it's an
403 on a per-mock-object basis.
405 Suppose your test uses a mock class `MockFoo`:
470 1. `NiceMock<MockFoo>` and `StrictMock<MockFoo>` only work for mock methods
472 If a mock method is defined in a **base class** of `MockFoo`, the "nice" or
483 shouldn't need to update any tests. If your code interacts with a naggy mock,
485 change. Worse, if your code interacts with a strict mock, your tests may start
508 argument is not even 0-terminated). If we mock it as is, using the mock will be
512 The trick is to redispatch the method in the mock class:
526 // Implements the mock method:
537 By defining a new mock method with a trimmed argument list, we make the mock
567 may be tempted to make the methods of `Concrete` virtual and then mock it.
584 top of `Concrete`. In tests, you can easily mock that interface to observe how
651 Now you want to mock this interface such that you can set expectations on it.
653 it in the mock object is, well, a lot of work.
655 When you define the mock class using gMock, you can have it delegate its default
661 // Normal mock method definitions using gMock.
677 FakeFoo fake_; // Keeps an instance of the fake in the mock.
715 mock function (the one you specify inside the parentheses of `ON_CALL()`),
725 * Having to mix a mock and a fake is often a sign of something gone wrong.
731 Regarding the tip on mixing a mock and a fake, here's an example on why it may
735 operations to work normally. If you mock out the entire `System` class, you'll
740 `System`'s functionalities into the two. Then you can mock `IOOps` without
752 You can use the *delegating-to-real* technique to ensure that your mock has the
781 MockFoo mock;
782 EXPECT_CALL(mock, DoThis())
784 EXPECT_CALL(mock, DoThat("Hi"))
786 ... use mock in test ...
797 reality, sometimes you do need to mock a virtual method that is not pure (i.e,
820 perhaps your test doesn't need to mock `Concrete()` at all (but it would be
821 oh-so painful to have to define a new mock class whenever you don't need to mock
833 or tell the mock object that you don't want to mock `Concrete()`:
850 You can specify exactly which arguments a mock method is expecting:
1031 When a mock method is called, the *last* matching expectation that's still
1055 The `With()` clause allows us to match all arguments of a mock function as a
1199 Often a mock function takes a reference to object as an argument. When matching
1317 Imagine you have a mock function that takes an object of type `Foo`, which has
1357 Sometimes an STL container (e.g. list, vector, map, ...) is passed to a mock
1378 EXPECT_CALL(mock, Foo(ElementsAre(1, Gt(0), _, 5)));
1393 EXPECT_CALL(mock, Foo(UnorderedElementsAre(1, Gt(0), _, 5)));
1407 EXPECT_CALL(mock, Foo(ElementsAreArray(expected_vector1)));
1411 EXPECT_CALL(mock, Foo(ElementsAreArray(expected_vector2)));
1423 EXPECT_CALL(mock, Foo(ElementsAreArray(expected_vector3, count)));
1487 matcher can never call a mock function, as that will affect the state of the
1488 mock object and gMock.
1496 There are basically two constructs for defining the behavior of a mock object:
1498 a mock method is called, but <em>doesn't imply any expectation on the method
1528 in your test fixture to set the common mock behavior shared by all tests in the
1536 If you are bothered by the "Uninteresting mock function call" message printed
1537 when a mock method without an `EXPECT_CALL` is called, you may use a `NiceMock`
1538 instead to suppress all such messages for the mock object, or suppress the
1545 If you are not interested in how a mock method is called, just don't say
1551 Please note that once you expressed interest in a particular mock method (via
1558 If a mock method shouldn't be called at all, explicitly say so:
1607 In gMock, `NiceMock` and `StrictMock` can be used to make a mock class "nice" or
1610 A **nice mock** suppresses uninteresting call *warnings*. It is less chatty than
1611 the default mock, but otherwise is the same. If a test fails with a default
1612 mock, it will also fail using a nice mock instead. And vice versa. Don't expect
1613 making a mock nice to change the test's result.
1615 A **strict mock** turns uninteresting call warnings into errors. So making a
1616 mock strict may change the test's result.
1633 will be an unexpected call, and thus an error. *Having a nice mock doesn't
1674 supplying a [simpler mock interface](#SimplerInterfaces) than the mocked class
1774 When a mock method is called, gMock only considers expectations that are still
1829 If a mock function's return type is a reference, you need to use `ReturnRef()`
1855 If the mock function's return type is a reference, you can do it using
1857 Methods"). However, gMock doesn't let you use `ReturnRef()` in a mock function
1888 of the mock function at the time when the action is *created*, not when it is
1964 argument. To mock side effects, in general you can define your own action by
1992 If the mock method also needs to return a value as well, you can chain
2059 If you expect a call to change the behavior of a mock object, you can use
2083 and make a mock method get its return value from that variable:
2105 If a mock method's return type is a built-in C++ type or pointer, by default it
2106 will return 0 when invoked. Also, in C++ 11 and above, a mock method whose
2144 code that uses your mock.
2149 may be too coarse for your purpose: perhaps you have two mock methods with the
2151 macro allows you to customize your mock's behavior at the method level:
2177 order allows you to set up the common behavior in a mock object's constructor or
2178 the test fixture's set-up phase and specialize the mock's behavior later.
2224 with the signature of the mock function, meaning that the latter's arguments (if
2228 mock function, as long as it's safe to do so - nice, huh?
2250 arguments as the mock function you use it for. Sometimes you may have a function
2279 `Invoke()` passes the mock function's arguments to the function, etc being
2285 the arguments of the mock function. She could do that using a wrapper function
2291 `Invoke()` except that it doesn't pass the mock function's arguments to the
2336 Sometimes a mock function will receive a function pointer, a functor (in other
2362 Arghh, you need to refer to a mock function argument but C++ has no lambda
2371 will invoke the `N`-th (0-based) argument the mock function receives, with
2436 that returns `void` (perhaps you want to use it in a mock function that returns
2473 Say you have a mock function `Foo()` that takes seven arguments, and you have a
2490 EXPECT_CALL(mock, Foo)
2507 EXPECT_CALL(mock, Foo)
2520 creates an action that passes the arguments of the mock function at the given
2529 EXPECT_CALL(mock, Foo)
2552 if the 4-th argument of the mock function is an `int` and `my_action` takes
2558 to make a mock function and an action with incompatible argument lists fit
2589 EXPECT_CALL(mock, Foo("abc", _, _))
2591 EXPECT_CALL(mock, Bar(5, _, _))
2606 EXPECT_CALL(mock, Foo("abc", _, _))
2608 EXPECT_CALL(mock, Bar(5, _, _))
2673 easily mock it out. However, the implementation of the class fired all the
2748 need to mock `Buzzer` in our tests.
2750 To mock a method that accepts or returns move-only types, you just use the
2762 Now that we have the mock class defined, we can use it in tests. In the
2808 If you need your mock method to do more than just moving a pre-defined value,
2866 The trick is to delegate the `ShareBuzz()` method to a mock method (let’s call
2868 setting expectations on `ShareBuzz()`, you set them on the `DoShareBuzz()` mock
2883 Believe it or not, the *vast majority* of the time spent on compiling a mock
2885 non-trivial tasks (e.g. verification of the expectations). What's more, mock
2888 result, if you mock many different types of methods, compiling your mock class
2892 mock class' constructor and destructor out of the class body and into a `.cc`
2893 file. This way, even if you `#include` your mock class in N files, the compiler
2897 Let's illustrate the idea using an example. Here's the definition of a mock
2907 // where this mock class is used.
2911 ... more mock methods ...
2928 ... more mock methods ...
2940 // variables used to implement the mock methods.
2947 When it's being destroyed, your friendly mock object will automatically verify
2950 worry about. That is, unless you are not sure if your mock object will be
2953 How could it be that your mock object won't eventually be destroyed? Well, it
2955 there's a bug in that code and it doesn't delete the mock object properly - you
2960 to verify a mock object before it is (hopefully) destructed. You can do this
2987 Do not set new expectations after verifying and clearing a mock after its use.
2988 Setting expectations after code that exercises the mock has undefined behavior.
2994 Sometimes you might want to test a mock object's behavior in phases whose sizes
2996 which API calls invoke which mock functions.
3000 that the mock function calls do happen at the right time. For example, if you
3009 and want to verify that `Foo(1)` and `Foo(3)` both invoke `mock.Bar("a")`, but
3016 MyMock mock;
3017 // Class MockFunction<F> has exactly one mock method. It is named
3023 EXPECT_CALL(mock, Bar("a"));
3026 EXPECT_CALL(mock, Bar("a"));
3043 Sometimes you want to make sure a mock object is destructed at the right time,
3045 that you can specify constraints on the [order](#OrderedCalls) of mock function
3046 calls, so all we need to do is to mock the destructor of the mock function.
3057 First, add a mock function `Die()` to your mock class and call it in the
3063 // Add the following two lines to the mock class.
3098 Remember the steps for using a mock:
3100 1. Create a mock object `foo`.
3104 4. Optionally, verify and reset the mock.
3105 5. Destroy the mock yourself, or let the code under test destroy it. The
3120 If you violate the rules (for example, if you set expectations on a mock while
3124 gMock guarantees that the action for a mock function is done in the same thread
3125 that called the mock function. For example, in
3128 EXPECT_CALL(mock, Foo(1))
3130 EXPECT_CALL(mock, Foo(2))
3144 affects *all* living mock objects in your program. Naturally, you won't want to
3149 When gMock sees something that has the potential of being an error (e.g. a mock
3159 observe every mock call that happens (including argument values, the return
3194 `EXPECT_CALL`s and mock method calls as they are made? For each call, would you
3197 about being able to see the complete stack trace at each mock call?
3215 MockFoo mock;
3216 EXPECT_CALL(mock, F(_, _)).WillRepeatedly(Return());
3217 EXPECT_CALL(mock, F("a", "b"));
3218 EXPECT_CALL(mock, F("c", HasSubstr("d")));
3220 mock.F("a", "good");
3221 mock.F("a", "b");
3230 foo_test.cc:14: EXPECT_CALL(mock, F(_, _)) invoked
3233 foo_test.cc:15: EXPECT_CALL(mock, F("a", "b")) invoked
3236 foo_test.cc:16: EXPECT_CALL(mock, F("c", HasSubstr("d"))) invoked
3239 foo_test.cc:14: Mock function call matches EXPECT_CALL(mock, F(_, _))...
3243 foo_test.cc:15: Mock function call matches EXPECT_CALL(mock, F("a", "b"))...
3248 Actual function call count doesn't match EXPECT_CALL(mock, F("c", HasSubstr("d")))...
3260 If you are interested in the mock call trace but not the stack traces, you can
3858 MockFunction<int(int)> mock;
3859 EXPECT_CALL(mock, Call).WillOnce([](const int input) { return input * 7; });
3860 EXPECT_EQ(mock.AsStdFunction()(2), 14);
3878 supplied to the mock function:
3881 MockFunction<int(int)> mock;
3882 EXPECT_CALL(mock, Call).WillOnce([] { return 17; });
3883 EXPECT_EQ(mock.AsStdFunction()(0), 17);
3899 MockFunction<std::unique_ptr<int>()> mock;
3900 EXPECT_CALL(mock, Call).WillOnce(MoveOnlyAction{std::make_unique<int>(17)});
3901 EXPECT_THAT(mock.AsStdFunction()(), Pointee(Eq(17)));
3904 More generally, to use with a mock function whose signature is `R(Args...)` the
3916 specific return type of the mock function can define templated conversion
3936 statements, you can refer to the K-th (0-based) argument of the mock function as
3949 Note that you don't need to specify the types of the mock function arguments.
3952 compatible with the mock function's return type.
3972 `argK_type` | The type of the K-th (0-based) argument of the mock function
3974 `args` | All arguments of the mock function as a tuple
3975 `args_type` | The type of all arguments of the mock function as a tuple
3976 `return_type` | The return type of the mock function
3977 `function_type` | The type of the mock function
3979 For example, when using an `ACTION` as a stub action for mock function:
4021 mock function, and the term *parameters* for the values used to instantiate an
4060 provide the types of the mock function arguments and the action parameters.
4108 // DuplicateArg<k, T>(output) converts the k-th argument of the mock
4131 EXPECT_CALL(mock, Foo).WillOnce(DuplicateArg<1, unsigned char>(&n));
4181 they don't let you directly specify the types of the mock function arguments and
4187 `::testing::ActionInterface<F>`, where `F` is the type of the mock function in
4242 If an action can be used in several types of mock functions, we say it's
4254 mock function's argument list. The first step is to define an implementation
4270 template takes the mock function's arguments as a tuple in a **single**
4274 the mock function's return type and `args` is its arguments in a tuple.
4334 and are not usually passed around by pointer, which makes them tricky to mock.
4337 `MockFunction<R(T1, ..., Tn)>` has a mock method `Call()` with the signature:
4356 // 1. Create a mock object.