Lines Matching +full:overloaded +full:- +full:virtual
30 * **`const`** - Makes the mocked method a `const` method. Required if
32 * **`override`** - Marks the method with `override`. Recommended if overriding
33 a `virtual` method.
34 * **`noexcept`** - Marks the method with `noexcept`. Required if overriding a
36 * **`Calltype(...)`** - Sets the call type for the method (e.g. to
38 * **`ref(...)`** - Marks the method with the reference qualification
56 Solution 1 - wrap with parentheses:
70 Solution 2 - define an alias:
89 (Yes, C++ allows a subclass to change the access level of a virtual function in
96 virtual bool Transform(Gadget* g) = 0;
99 virtual void Resume();
102 virtual int GetTimeOut();
117 ### Mocking Overloaded Methods
119 You can mock overloaded functions as usual. No special attention is required:
125 // Must be virtual as we'll inherit from Foo.
126 virtual ~Foo();
128 // Overloaded on the types and/or numbers of arguments.
129 virtual int Add(Element x);
130 virtual int Add(int times, Element x);
132 // Overloaded on the const-ness of this object.
133 virtual Bar& GetBar();
134 virtual const Bar& GetBar() const;
148 **Note:** if you don't mock all versions of the overloaded method, the compiler
170 // Must be virtual as we'll inherit from StackInterface.
171 virtual ~StackInterface();
173 virtual int GetSize() const = 0;
174 virtual void Push(const Elem& x) = 0;
185 ### Mocking Non-virtual Methods {#MockingNonVirtualMethods}
187 gMock can mock non-virtual functions to be used in Hi-perf dependency injection.
191 same signatures. The syntax for mocking non-virtual methods is the *same* as
192 mocking virtual methods (just don't add `override`):
195 // A simple packet stream class. None of its members is virtual.
219 not virtual and the two classes are unrelated, you must specify your choice at
254 It is not possible to directly mock a free function (i.e. a C-style function or
265 virtual bool Open(const char* path, const char* mode) = 0;
281 related functions that you can put in the same interface, so the per-function
284 If you are concerned about the performance overhead incurred by virtual
286 recipe for [mocking non-virtual methods](#MockingNonVirtualMethods).
288 ### Old-Style `MOCK_METHODn` Macros
399 on a per-mock-object basis.
461 [Understanding Uninteresting vs Unexpected Calls](#uninteresting-vs-unexpected).
473 destructor of `MockFoo` is not virtual. We would like to fix this, but it
496 virtual void send(LogSeverity severity, const char* full_filename,
504 argument is not even 0-terminated). If we mock it as is, using the mock will be
534 class more user-friendly.
536 This technique may also be applied to make overloaded methods more amenable to
563 may be tempted to make the methods of `Concrete` virtual and then mock it.
567 Making a non-virtual function virtual is a big decision. It creates an extension
570 should make a function virtual only when there is a valid reason for a subclass
574 between the class and the tests - any small change in the class may invalidate
585 * You pay the cost of virtual function calls (usually not a problem).
593 have a chance to tailor it to your need - you may add higher-level
609 own domain-specific interface on top of `Concrete`, and they will not be the
614 sub-directory) and let many projects use it.
619 situations. :-)
623 Some times you have a non-trivial fake implementation of an interface. For
629 virtual ~Foo() {}
630 virtual char DoThis(int n) = 0;
631 virtual void DoThat(const char* s, int* p) = 0;
638 (n < 0) ? '-' : '0';
709 * The general technique discussed here works for overloaded methods, but
718 (The strange-looking thing inside the angled brackets of `static_cast` is
722 Perhaps you haven't got used to the interaction-based way of testing yet. Or
728 be a bad sign: Suppose you have a class `System` for low-level system
748 You can use the *delegating-to-real* technique to ensure that your mock has the
750 This technique is very similar to the [delegating-to-fake](#DelegatingToFake)
792 Ideally, you should code to interfaces, whose methods are all pure virtual. In
793 reality, sometimes you do need to mock a virtual method that is not pure (i.e,
799 virtual ~Foo();
801 virtual void Pure(int n) = 0;
802 virtual int Concrete(const char* str) { ... }
817 oh-so painful to have to define a new mock class whenever you don't need to mock
840 `Foo::Concrete()` is virtual. That's just how C++ works.)
892 // The first argument must not contain sub-string "blah".
922 is nothing really wrong with using a `Matcher<long>` to match an `int` - after
931 2. When both `T` and `U` are built-in arithmetic types (`bool`, integers, and
932 floating-point numbers), the conversion from `T` to `U` is not lossy (in
968 ### Selecting Between Overloaded Functions {#SelectOverload}
970 If you expect an overloaded function to be called, the compiler may need some
971 help on which overloaded version it is.
973 To disambiguate functions overloaded on the const-ness of this object, use the
988 EXPECT_CALL(foo, GetBar()) // The non-const GetBar().
996 To disambiguate overloaded functions with the same number of arguments but
1089 As a convenience and example, gMock provides some matchers for 2-tuples,
1091 [Multi-argument Matchers](reference/matchers.md#MultiArgMatchers) for the
1144 gMock provides a set of built-in matchers for matching arguments with expected
1146 In case you find the built-in set lacking, you can use an arbitrary unary
1147 predicate function or functor as a matcher - as long as the predicate accepts a
1197 object, as that may be over-specification. Instead, you may need to validate a
1218 | :--------------------------- | :--------------------------------------- |
1237 matches a plain pointer `p` where `p->number >= 3`. If `p` is `NULL`, the match
1297 What if you have a pointer to pointer? You guessed it - you can use nested
1361 elements, and having to define the expected container out-of-line is a bit of a
1395 As an alternative you can place the arguments in a C-style array and use
1442 container types yet to be written - as long as they follows the above
1444 * You can use nested `ElementsAre*()` to match nested (multi-dimensional)
1454 Under the hood, a gMock matcher object consists of a pointer to a ref-counted
1473 ### Matchers must have no side-effects {#PureMatchers}
1490 **`ON_CALL`** is likely the *single most under-utilized construct* in gMock.
1502 more constraints than necessary is *baaad* - even worse than not having enough
1505 This may be counter-intuitive. How could tests that verify more be worse than
1509 contract of the code.** If a test over-specifies, it doesn't leave enough
1578 ### Understanding Uninteresting vs Unexpected Calls {#uninteresting-vs-unexpected}
1667 This functionality is only available when a method is not overloaded; to prevent
1707 a call to `foo.DoThis(6)`. If a call occurred out-of-order, gMock will report an
1755 specifies the following DAG (where `s1` is `A -> B`, and `s2` is `A -> C -> D`):
1758 +---> B
1760 A ---|
1762 +---> C ---> D
1804 and result in an upper-bound-violated error.
1818 `"File too large."`, the first will match #2 and the second will match #1 -
1957 If all you need to do is to change an output argument, the built-in
1976 `int` variable pointed to by argument #1 (0-based).
2010 array pointed to by the `N`-th (0-based) argument:
2095 If a mock method's return type is a built-in C++ type or pointer, by default it
2097 return type has a default constructor will return a default-constructed value by
2150 .WillByDefault(Return(-1));
2160 foo.Sign(-9); // This should return -1.
2168 the test fixture's set-up phase and specialize the mock's behavior later.
2176 If the built-in actions don't suit you, you can use an existing callable
2210 foo.ComplexJob(-1); // Invokes the inline lambda.
2218 mock function, as long as it's safe to do so - nice, huh?
2243 pre-bound arguments. Here's an example:
2255 return (sum > 0) ? '+' : (sum < 0) ? '-' : '0';
2345 // Will execute callback->Run(5), where callback is the
2353 (yet), so you have to define your own action. :-( Or do you really?
2361 will invoke the `N`-th (0-based) argument the mock function receives, with
2373 // Will execute callback->Run(5), where callback is the
2377 What if the callable takes an argument by reference? No problem - just wrap it
2481 .WillOnce(Invoke(IsVisibleInQuadrant1)); // Uh, won't compile. :-(
2511 indices (0-based) to the inner `action` and performs it. Using `WithArgs`, our
2535 `Invoke()` -- it can be anything.
2542 if the 4-th argument of the mock function is an `int` and `my_action` takes
2547 The [selecting-an-action's-arguments](#SelectingArgs) recipe showed us one way
2604 Just like matchers, a gMock action object consists of a pointer to a ref-counted
2639 foo.DoThat(); // Returns 1 - Blah() uses a different
2655 foo.DoThat(); // Returns 3 - the counter is shared.
2660 One oft-encountered problem with gMock is that it can be hard to test
2696 our test will run forever. It will eventually time-out and fail, but it will
2702 ### Mocking Methods That Use Move-Only Types
2704 C++11 introduced *move-only types*. A move-only-typed value can be moved from
2706 the most commonly used move-only type.
2708 Mocking a method that takes and/or returns move-only types presents some
2710 Note that the support for move-only method arguments was only introduced to
2728 virtual ~Buzzer() {}
2729 virtual std::unique_ptr<Buzz> MakeBuzz(StringPiece text) = 0;
2730 virtual bool ShareBuzz(std::unique_ptr<Buzz> buzz, int64_t timestamp) = 0;
2740 To mock a method that accepts or returns move-only types, you just use the
2780 If you just need to return a pre-defined move-only value, you can use the
2792 Note that `ByMove()` is essential here - if you drop it, the code won’t compile.
2797 the action runs, the source value will be consumed (since it’s a move-only
2798 value), so the next time around, there’s no value to move from -- you’ll get a
2799 run-time error that `Return(ByMove(...))` can only be run once.
2801 If you need your mock method to do more than just moving a pre-defined value,
2818 That covers returning move-only values; but how do we work with methods
2819 accepting move-only arguments? The answer is that they work normally, although
2820 some actions will not compile when any of method's arguments are move-only. You
2835 Many built-in actions (`WithArgs`, `WithoutArgs`,`DeleteArg`, `SaveArg`, ...)
2836 could in principle support move-only arguments, but the support for this is not
2840 work with non-copyable objects; you'll have to use functors instead.
2842 #### Legacy workarounds for move-only types {#LegacyMoveOnly}
2844 Support for move-only function arguments was only introduced to gMock in April
2846 of this feature (it is no longer necessary - we're including it just for
2860 it `DoShareBuzz()`) that does not take move-only parameters. Then, instead of
2878 non-trivial tasks (e.g. verification of the expectations). What's more, mock
2917 virtual ~MockFoo();
2948 there's a bug in that code and it doesn't delete the mock object properly - you
2982 See [Using Mocks in Tests](gmock_for_dummies.md#using-mocks-in-tests) for more
3037 e.g. after `bar->A()` is called but before `bar->B()` is called. We already know
3073 // Expects *foo to die after bar->A() and before bar->B().
3085 single-threaded context. That avoids race conditions and dead locks, and makes
3088 Yet most programs are multi-threaded, and sometimes to test something we need to
3109 * #3 and #4 can be done either in one thread or in multiple threads - anyway
3110 you want. gMock takes care of the locking, so you don't have to do any -
3134 `action1` and `action2` to make the test thread-safe.
3155 You can control how much gMock tells you using the `--gmock_verbose=LEVEL`
3156 command-line flag, where `LEVEL` is a string with three possible values:
3175 `--gtest_stack_trace_depth=max_depth` flag.
3186 Won't it be nice if you have X-ray vision and can actually see the trace of all
3192 You can unlock this power by running your test with the `--gmock_verbose=info`
3218 if you run it with `--gmock_verbose=info`, you will see this output:
3243 Actual: never called - unsatisfied and active
3254 combine `--gmock_verbose=info` with `--gtest_stack_trace_depth=0` on the test
3259 If you build and run your tests in Emacs using the `M-x google-compile` command
3262 taken to the offending line. Or, you can just type `C-x`` to jump to the next
3268 (global-set-key "\M-m" 'google-compile) ; m is for make
3269 (global-set-key [M-down] 'next-error)
3270 (global-set-key [M-up] '(lambda () (interactive) (next-error -1)))
3273 Then you can type `M-m` to start a build (if you want to run the test as well,
3275 after typing `M-m`), or `M-up`/`M-down` to move back and forth between errors.
3298 The *description string* is a `string`-typed expression that documents what the
3346 As you may have noticed, the auto-generated descriptions (especially those for
3381 match succeeds in case of a success (unless it's obvious) - this is useful when
3424 Actual: -9
3428 message human-friendly.
3436 support multi-parameter matchers:
3507 special types: you can assign `Foo()` to a `FooMatcher`-typed variable, and
3508 assign `Foo(p)` to a `FooMatcherP<p_type>`-typed variable.
3663 EXPECT_CALL(foo, Bar(NotNull())); // The argument must be a non-NULL pointer.
3669 several supporting classes and virtual functions. To implement a matcher for
3691 virtual ~MatcherInterface();
3695 virtual bool MatchAndExplain(T x, MatchResultListener* listener) const = 0;
3698 virtual void DescribeTo(std::ostream* os) const = 0;
3701 virtual void DescribeNegationTo(std::ostream* os) const;
3745 EXPECT_CALL(foo, Bar(NotNull())); // The argument must be a non-NULL pointer.
3751 virtual.
3762 If the [built-in set](gmock_cheat_sheet.md#CardinalityList) of cardinalities
3769 virtual ~CardinalityInterface();
3772 virtual bool IsSatisfiedByCallCount(int call_count) const = 0;
3776 virtual bool IsSaturatedByCallCount(int call_count) const = 0;
3779 virtual void DescribeTo(std::ostream* os) const = 0;
3817 If the built-in actions don't work for you, you can easily define your own one.
3851 once and is allowed to be a move-only type:
3854 // An action that contains move-only types and has an &&-qualified operator,
3871 weaker requirements (`Action` requires a copy-constructible input that can be
3872 called repeatedly whereas `OnceAction` requires only move-constructible and
3873 supports `&&`-qualified call operators), but can be used only with `WillOnce`.
3874 `OnceAction` is typically relevant only when supporting move-only types or
3875 actions that want a type-system guarantee that they will be called at most once.
3881 operators to make that possible. See `gmock-actions.h` for examples.
3883 #### Legacy macro-based Actions
3885 Before C++11, the functor-based actions were not supported; the old way of
3888 harder-to-understand compiler errors. Nevertheless, we cover them here for
3900 statements, you can refer to the K-th (0-based) argument of the mock function as
3914 Rest assured that your code is type-safe though: you'll get a compiler error if
3933 For more convenience and flexibility, you can also use the following pre-defined
3936 `argK_type` | The type of the K-th (0-based) argument of the mock function
3937 :-------------- | :-----------------------------------------------------------
3951 Pre-defined Symbol | Is Bound To
3952 ------------------ | ---------------------------------
3962 #### Legacy macro-based parameterized Actions
3989 the parameter is named `param`, you can also use the gMock-defined symbol
3994 gMock also provides `ACTION_P2`, `ACTION_P3`, and etc to support multi-parameter
3999 double dx = arg0 - x;
4000 double dy = arg1 - y;
4014 You can also easily define actions overloaded on the number of parameters:
4046 where `StaticAssertTypeEq` is a compile-time assertion in googletest that
4065 name of the *i*-th template parameter, and `kind_i` specifies whether it's a
4066 `typename`, an integral constant, or a template. `p_i` is the name of the *i*-th
4072 // DuplicateArg<k, T>(output) converts the k-th argument of the mock
4107 `ACTION_TEMPLATE` and `ACTION`/`ACTION_P*` can be overloaded on the number of
4115 Are we using a single-template-parameter action where `bool` refers to the type
4116 of `x`, or a two-template-parameter action where the compiler is asked to infer
4127 | ----------------------------- | ------------------- | --------------------- |
4139 definitions cannot be overloaded on the number of them.
4158 virtual ~ActionInterface();
4166 virtual Result Perform(const ArgumentTuple& args) = 0;
4226 // To get the i-th (0-based) argument, use std::get(args).
4253 Now, you can use this polymorphic action the same way you use the built-in ones:
4279 assertion fails. gMock and googletest do this using googletest's user-extensible
4282 This printer knows how to print built-in C++ types, native arrays, STL
4285 [The GoogleTest advanced guide](advanced.md#teaching-googletest-how-to-print-your-values)
4291 <!--#include file="includes/g3_testing_LOGs.md"-->
4292 <!--#include file="includes/g3_mock_callbacks.md"-->
4299 But fear not - `MockFunction` can help you with that.
4343 callback has bigger problems than being mockable. :-)