diff options
Diffstat (limited to 'docs/gmock_cook_book.md')
| -rw-r--r-- | docs/gmock_cook_book.md | 314 |
1 files changed, 152 insertions, 162 deletions
diff --git a/docs/gmock_cook_book.md b/docs/gmock_cook_book.md index 891c35cf..da10918c 100644 --- a/docs/gmock_cook_book.md +++ b/docs/gmock_cook_book.md @@ -285,6 +285,10 @@ 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). +Alternatively, instead of introducing a new interface, you can rewrite your code +to accept a std::function instead of the free function, and then use +[MockFunction](#MockFunction) to mock the std::function. + ### Old-Style `MOCK_METHODn` Macros Before the generic `MOCK_METHOD` macro @@ -392,8 +396,7 @@ Old macros and their new equivalents: 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 `ON_CALL()`) of the method will be taken. Currently, an uninteresting call will -also by default cause gMock to print a warning. (In the future, we might remove -this warning by default.) +also by default cause gMock to print a warning. However, sometimes you may want to ignore these uninteresting calls, and sometimes you may want to treat them as errors. gMock lets you make the decision @@ -694,9 +697,9 @@ TEST(AbcTest, Xyz) { EXPECT_CALL(foo, DoThat(_, _)); int n = 0; - EXPECT_EQ('+', foo.DoThis(5)); // FakeFoo::DoThis() is invoked. + EXPECT_EQ(foo.DoThis(5), '+'); // FakeFoo::DoThis() is invoked. foo.DoThat("Hi", &n); // FakeFoo::DoThat() is invoked. - EXPECT_EQ(2, n); + EXPECT_EQ(n, 2); } ``` @@ -905,7 +908,7 @@ using ::testing::Contains; using ::testing::Property; inline constexpr auto HasFoo = [](const auto& f) { - return Property(&MyClass::foo, Contains(f)); + return Property("foo", &MyClass::foo, Contains(f)); }; ... EXPECT_THAT(x, HasFoo("blah")); @@ -1084,7 +1087,7 @@ using ::testing::Lt; ``` says that `Blah` will be called with arguments `x`, `y`, and `z` where `x < y < -z`. Note that in this example, it wasn't necessary specify the positional +z`. Note that in this example, it wasn't necessary to specify the positional matchers. As a convenience and example, gMock provides some matchers for 2-tuples, @@ -1126,62 +1129,19 @@ using STL's `<functional>` header is just painful). For example, here's a predicate that's satisfied by any number that is >= 0, <= 100, and != 50: ```cpp -using testing::AllOf; -using testing::Ge; -using testing::Le; -using testing::Matches; -using testing::Ne; -... -Matches(AllOf(Ge(0), Le(100), Ne(50))) -``` - -### Using Matchers in googletest Assertions - -Since matchers are basically predicates that also know how to describe -themselves, there is a way to take advantage of them in googletest assertions. -It's called `ASSERT_THAT` and `EXPECT_THAT`: - -```cpp - ASSERT_THAT(value, matcher); // Asserts that value matches matcher. - EXPECT_THAT(value, matcher); // The non-fatal version. -``` - -For example, in a googletest test you can write: - -```cpp -#include "gmock/gmock.h" - using ::testing::AllOf; using ::testing::Ge; using ::testing::Le; -using ::testing::MatchesRegex; -using ::testing::StartsWith; - +using ::testing::Matches; +using ::testing::Ne; ... - EXPECT_THAT(Foo(), StartsWith("Hello")); - EXPECT_THAT(Bar(), MatchesRegex("Line \\d+")); - ASSERT_THAT(Baz(), AllOf(Ge(5), Le(10))); +Matches(AllOf(Ge(0), Le(100), Ne(50))) ``` -which (as you can probably guess) executes `Foo()`, `Bar()`, and `Baz()`, and -verifies that: - -* `Foo()` returns a string that starts with `"Hello"`. -* `Bar()` returns a string that matches regular expression `"Line \\d+"`. -* `Baz()` returns a number in the range [5, 10]. - -The nice thing about these macros is that *they read like English*. They -generate informative messages too. For example, if the first `EXPECT_THAT()` -above fails, the message will be something like: - -```cpp -Value of: Foo() - Actual: "Hi, world!" -Expected: starts with "Hello" -``` +### Using Matchers in googletest Assertions -**Credit:** The idea of `(ASSERT|EXPECT)_THAT` was borrowed from Joe Walnes' -Hamcrest project, which adds `assertThat()` to JUnit. +See [`EXPECT_THAT`](reference/assertions.md#EXPECT_THAT) in the Assertions +Reference. ### Using Predicates as Matchers @@ -1202,7 +1162,7 @@ int IsEven(int n) { return (n % 2) == 0 ? 1 : 0; } ``` Note that the predicate function / functor doesn't have to return `bool`. It -works as long as the return value can be used as the condition in in statement +works as long as the return value can be used as the condition in the statement `if (condition) ...`. ### Matching Arguments that Are Not Copyable @@ -1343,23 +1303,27 @@ What if you have a pointer to pointer? You guessed it - you can use nested `Pointee(Pointee(Lt(3)))` matches a pointer that points to a pointer that points to a number less than 3 (what a mouthful...). -### Testing a Certain Property of an Object +### Defining a Custom Matcher Class {#CustomMatcherClass} -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 -quick and dirty, you could get away with writing an ordinary function. +Most matchers can be simply defined using [the MATCHER* macros](#NewMatchers), +which are terse and flexible, and produce good error messages. However, these +macros are not very explicit about the interfaces they create and are not always +suitable, especially for matchers that will be widely reused. -Let's say you have a mock function that takes an object of type `Foo`, which has -an `int bar()` method and an `int baz()` method, and you want to constrain that -the argument's `bar()` value plus its `baz()` value is a given number. Here's -how you can define a matcher to do it: +For more advanced cases, you may need to define your own matcher class. A custom +matcher allows you to test a specific invariant property of that object. Let's +take a look at how to do so. -```cpp -using ::testing::Matcher; +Imagine you have a mock function that takes an object of type `Foo`, which has +an `int bar()` method and an `int baz()` method. You want to constrain that the +argument's `bar()` value plus its `baz()` value is a given number. (This is an +invariant.) Here's how we can write and use a matcher class to do so: +```cpp class BarPlusBazEqMatcher { public: + using is_gtest_matcher = void; + explicit BarPlusBazEqMatcher(int expected_sum) : expected_sum_(expected_sum) {} @@ -1368,23 +1332,24 @@ class BarPlusBazEqMatcher { return (foo.bar() + foo.baz()) == expected_sum_; } - void DescribeTo(std::ostream& os) const { - os << "bar() + baz() equals " << expected_sum_; + void DescribeTo(std::ostream* os) const { + *os << "bar() + baz() equals " << expected_sum_; } - void DescribeNegationTo(std::ostream& os) const { - os << "bar() + baz() does not equal " << expected_sum_; + void DescribeNegationTo(std::ostream* os) const { + *os << "bar() + baz() does not equal " << expected_sum_; } private: const int expected_sum_; }; -Matcher<const Foo&> BarPlusBazEq(int expected_sum) { +::testing::Matcher<const Foo&> BarPlusBazEq(int expected_sum) { return BarPlusBazEqMatcher(expected_sum); } ... - EXPECT_CALL(..., DoThis(BarPlusBazEq(5)))...; + Foo foo; + EXPECT_THAT(foo, BarPlusBazEq(5))...; ``` ### Matching Containers @@ -1463,11 +1428,12 @@ Use `Pair` when comparing maps or other associative containers. {% raw %} ```cpp -using testing::ElementsAre; -using testing::Pair; +using ::testing::UnorderedElementsAre; +using ::testing::Pair; ... - std::map<string, int> m = {{"a", 1}, {"b", 2}, {"c", 3}}; - EXPECT_THAT(m, ElementsAre(Pair("a", 1), Pair("b", 2), Pair("c", 3))); + absl::flat_hash_map<string, int> m = {{"a", 1}, {"b", 2}, {"c", 3}}; + EXPECT_THAT(m, UnorderedElementsAre( + Pair("a", 1), Pair("b", 2), Pair("c", 3))); ``` {% endraw %} @@ -1484,8 +1450,8 @@ using testing::Pair; * If the container is passed by pointer instead of by reference, just write `Pointee(ElementsAre*(...))`. * The order of elements *matters* for `ElementsAre*()`. If you are using it - with containers whose element order are undefined (e.g. `hash_map`) you - should use `WhenSorted` around `ElementsAre`. + with containers whose element order are undefined (such as a + `std::unordered_map`) you should use `UnorderedElementsAre`. ### Sharing Matchers @@ -1495,7 +1461,7 @@ the pointer is copied. When the last matcher that references the implementation object dies, the implementation object will be deleted. Therefore, if you have some complex matcher that you want to use again and -again, there is no need to build it everytime. Just assign it to a matcher +again, there is no need to build it every time. Just assign it to a matcher variable and use that variable repeatedly! For example, ```cpp @@ -1754,7 +1720,7 @@ 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](gmock_cheat_sheet.md#AfterClause) clause of `EXPECT_CALL`. +[`After` clause](reference/mocking.md#EXPECT_CALL.After) of `EXPECT_CALL`. Another way is via the `InSequence()` clause (not the same as the `InSequence` class), which we borrowed from jMock 2. It's less flexible than `After()`, but @@ -1797,7 +1763,7 @@ specifies the following DAG (where `s1` is `A -> B`, and `s2` is `A -> C -> D`): | A ---| | - +---> C ---> D + +---> C ---> D ``` This means that A must occur before B and C, and C must occur before D. There's @@ -1895,7 +1861,7 @@ error. So, what shall you do? Though you may be tempted, DO NOT use `std::ref()`: ```cpp -using testing::Return; +using ::testing::Return; class MockFoo : public Foo { public: @@ -1907,7 +1873,7 @@ class MockFoo : public Foo { EXPECT_CALL(foo, GetValue()) .WillRepeatedly(Return(std::ref(x))); // Wrong! x = 42; - EXPECT_EQ(42, foo.GetValue()); + EXPECT_EQ(foo.GetValue(), 42); ``` Unfortunately, it doesn't work here. The above code will fail with error: @@ -1929,20 +1895,20 @@ the expectation is set, and `Return(std::ref(x))` will always return 0. returns the value pointed to by `pointer` at the time the action is *executed*: ```cpp -using testing::ReturnPointee; +using ::testing::ReturnPointee; ... int x = 0; MockFoo foo; EXPECT_CALL(foo, GetValue()) .WillRepeatedly(ReturnPointee(&x)); // Note the & here. x = 42; - EXPECT_EQ(42, foo.GetValue()); // This will succeed now. + EXPECT_EQ(foo.GetValue(), 42); // This will succeed now. ``` ### Combining Actions Want to do more than one thing when a function is called? That's fine. `DoAll()` -allow you to do sequence of actions every time. Only the return value of the +allows you to do a sequence of actions every time. Only the return value of the last action in the sequence will be used. ```cpp @@ -2023,6 +1989,7 @@ If the mock method also needs to return a value as well, you can chain ```cpp using ::testing::_; +using ::testing::DoAll; using ::testing::Return; using ::testing::SetArgPointee; @@ -2076,10 +2043,7 @@ class MockRolodex : public Rolodex { } ... MockRolodex rolodex; - vector<string> names; - names.push_back("George"); - names.push_back("John"); - names.push_back("Thomas"); + vector<string> names = {"George", "John", "Thomas"}; EXPECT_CALL(rolodex, GetNames(_)) .WillOnce(SetArrayArgument<0>(names.begin(), names.end())); ``` @@ -2300,7 +2264,7 @@ TEST_F(FooTest, Test) { EXPECT_CALL(foo, DoThis(2)) .WillOnce(Invoke(NewPermanentCallback(SignOfSum, 5))); - EXPECT_EQ('+', foo.DoThis(2)); // Invokes SignOfSum(5, 2). + EXPECT_EQ(foo.DoThis(2), '+'); // Invokes SignOfSum(5, 2). } ``` @@ -2647,7 +2611,7 @@ efficient. When the last action that references the implementation object dies, the implementation object will be deleted. If you have some complex action that you want to use again and again, you may -not have to build it from scratch everytime. If the action doesn't have an +not have to build it from scratch every time. If the action doesn't have an internal state (i.e. if it always does the same thing no matter how many times it has been called), you can assign it to an action variable and use that variable repeatedly. For example: @@ -2676,8 +2640,8 @@ action will exhibit different behaviors. Example: .WillRepeatedly(IncrementCounter(0)); foo.DoThis(); // Returns 1. foo.DoThis(); // Returns 2. - foo.DoThat(); // Returns 1 - Blah() uses a different - // counter than Bar()'s. + foo.DoThat(); // Returns 1 - DoThat() uses a different + // counter than DoThis()'s. ``` versus @@ -2807,36 +2771,33 @@ returns a null `unique_ptr`, that’s what you’ll get if you don’t specify a action: ```cpp +using ::testing::IsNull; +... // Use the default action. EXPECT_CALL(mock_buzzer_, MakeBuzz("hello")); // Triggers the previous EXPECT_CALL. - EXPECT_EQ(nullptr, mock_buzzer_.MakeBuzz("hello")); + EXPECT_THAT(mock_buzzer_.MakeBuzz("hello"), IsNull()); ``` If you are not happy with the default action, you can tweak it as usual; see [Setting Default Actions](#OnCall). -If you just need to return a pre-defined move-only value, you can use the -`Return(ByMove(...))` action: +If you just need to return a move-only value, you can use it in combination with +`WillOnce`. For example: ```cpp - // When this fires, the unique_ptr<> specified by ByMove(...) will - // be returned. - EXPECT_CALL(mock_buzzer_, MakeBuzz("world")) - .WillOnce(Return(ByMove(MakeUnique<Buzz>(AccessLevel::kInternal)))); - - EXPECT_NE(nullptr, mock_buzzer_.MakeBuzz("world")); + EXPECT_CALL(mock_buzzer_, MakeBuzz("hello")) + .WillOnce(Return(std::make_unique<Buzz>(AccessLevel::kInternal))); + EXPECT_NE(nullptr, mock_buzzer_.MakeBuzz("hello")); ``` -Note that `ByMove()` is essential here - if you drop it, the code won’t compile. - -Quiz time! What do you think will happen if a `Return(ByMove(...))` action is -performed more than once (e.g. you write `... -.WillRepeatedly(Return(ByMove(...)));`)? Come think of it, after the first time -the action runs, the source value will be consumed (since it’s a move-only -value), so the next time around, there’s no value to move from -- you’ll get a -run-time error that `Return(ByMove(...))` can only be run once. +Quiz time! What do you think will happen if a `Return` action is performed more +than once (e.g. you write `... .WillRepeatedly(Return(std::move(...)));`)? Come +think of it, after the first time the action runs, the source value will be +consumed (since it’s a move-only value), so the next time around, there’s no +value to move from -- you’ll get a run-time error that `Return(std::move(...))` +can only be run once. If you need your mock method to do more than just moving a pre-defined value, remember that you can always use a lambda or a callable object, which can do @@ -2845,7 +2806,7 @@ pretty much anything you want: ```cpp EXPECT_CALL(mock_buzzer_, MakeBuzz("x")) .WillRepeatedly([](StringPiece text) { - return MakeUnique<Buzz>(AccessLevel::kInternal); + return std::make_unique<Buzz>(AccessLevel::kInternal); }); EXPECT_NE(nullptr, mock_buzzer_.MakeBuzz("x")); @@ -2853,7 +2814,7 @@ pretty much anything you want: ``` Every time this `EXPECT_CALL` fires, a new `unique_ptr<Buzz>` will be created -and returned. You cannot do this with `Return(ByMove(...))`. +and returned. You cannot do this with `Return(std::make_unique<...>(...))`. 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 @@ -2864,7 +2825,7 @@ can always use `Return`, or a [lambda or functor](#FunctionsAsActions): using ::testing::Unused; EXPECT_CALL(mock_buzzer_, ShareBuzz(NotNull(), _)).WillOnce(Return(true)); - EXPECT_TRUE(mock_buzzer_.ShareBuzz(MakeUnique<Buzz>(AccessLevel::kInternal)), + EXPECT_TRUE(mock_buzzer_.ShareBuzz(std::make_unique<Buzz>(AccessLevel::kInternal)), 0); EXPECT_CALL(mock_buzzer_, ShareBuzz(_, _)).WillOnce( @@ -2908,7 +2869,7 @@ method: // 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), 0); + mock_buzzer_.ShareBuzz(std::make_unique<Buzz>(AccessLevel::kInternal), 0); ``` ### Making the Compilation Faster @@ -3017,31 +2978,21 @@ 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} - -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 -object have been satisfied, and then you set some new expectations on it as if -it's newly created. This allows you to work with a mock object in "phases" whose -sizes are each manageable. +Do not set new expectations after verifying and clearing a mock after its use. +Setting expectations after code that exercises the mock has undefined behavior. +See [Using Mocks in Tests](gmock_for_dummies.md#using-mocks-in-tests) for more +information. -One such scenario is that in your test's `SetUp()` function, you may want to put -the object you are testing into a certain state, with the help from a mock -object. Once in the desired state, you want to clear all expectations on the -mock, such that in the `TEST_F` body you can set fresh expectations on it. +### Using Checkpoints {#UsingCheckPoints} -As you may have figured out, the `Mock::VerifyAndClearExpectations()` function -we saw in the previous recipe can help you here. Or, if you are using -`ON_CALL()` to set default actions on the mock object and want to clear the -default actions as well, use `Mock::VerifyAndClear(&mock_object)` instead. This -function does what `Mock::VerifyAndClearExpectations(&mock_object)` does and -returns the same `bool`, **plus** it clears the `ON_CALL()` statements on -`mock_object` too. +Sometimes you might want to test a mock object's behavior in phases whose sizes +are each manageable, or you might want to set more detailed expectations about +which API calls invoke which mock functions. -Another trick you can use to achieve the same effect is to put the expectations -in sequences and insert calls to a dummy "check-point" function at specific -places. Then you can verify that the mock function calls do happen at the right -time. For example, if you are exercising code: +A technique you can use is to put the expectations in a sequence and insert +calls to a dummy "checkpoint" function at specific places. Then you can verify +that the mock function calls do happen at the right time. For example, if you +are exercising the code: ```cpp Foo(1); @@ -3050,7 +3001,7 @@ time. For example, if you are exercising code: ``` and want to verify that `Foo(1)` and `Foo(3)` both invoke `mock.Bar("a")`, but -`Foo(2)` doesn't invoke anything. You can write: +`Foo(2)` doesn't invoke anything, you can write: ```cpp using ::testing::MockFunction; @@ -3076,10 +3027,10 @@ TEST(FooTest, InvokesBarCorrectly) { } ``` -The expectation spec says that the first `Bar("a")` must happen before check -point "1", the second `Bar("a")` must happen after check point "2", and nothing -should happen between the two check points. The explicit check points make it -easy to tell which `Bar("a")` is called by which call to `Foo()`. +The expectation spec says that the first `Bar("a")` call must happen before +checkpoint "1", the second `Bar("a")` call must happen after checkpoint "2", and +nothing should happen between the two checkpoints. The explicit checkpoints make +it clear which `Bar("a")` is called by which call to `Foo()`. ### Mocking Destructors @@ -3243,11 +3194,11 @@ You can unlock this power by running your test with the `--gmock_verbose=info` flag. For example, given the test program: ```cpp -#include "gmock/gmock.h" +#include <gmock/gmock.h> -using testing::_; -using testing::HasSubstr; -using testing::Return; +using ::testing::_; +using ::testing::HasSubstr; +using ::testing::Return; class MockFoo { public: @@ -3373,7 +3324,7 @@ or, ```cpp using ::testing::Not; ... - // Verifies that two values are divisible by 7. + // Verifies that a value is divisible by 7 and the other is not. EXPECT_THAT(some_expression, IsDivisibleBy7()); EXPECT_THAT(some_other_expression, Not(IsDivisibleBy7())); ``` @@ -3862,35 +3813,74 @@ Cardinality EvenNumber() { .Times(EvenNumber()); ``` -### Writing New Actions Quickly {#QuickNewActions} +### Writing New Actions {#QuickNewActions} 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 -the signature of your action. +All you need is a call operator with a signature compatible with the mocked +function. So you can use a lambda: ```cpp -struct Increment { - template <typename T> - T operator()(T* arg) { - return ++(*arg); - } -} +MockFunction<int(int)> mock; +EXPECT_CALL(mock, Call).WillOnce([](const int input) { return input * 7; }); +EXPECT_EQ(mock.AsStdFunction()(2), 14); ``` -The same approach works with stateful functors (or any callable, really): +Or a struct with a call operator (even a templated one): -``` +```cpp struct MultiplyBy { template <typename T> T operator()(T arg) { return arg * multiplier; } int multiplier; -} +}; // Then use: // EXPECT_CALL(...).WillOnce(MultiplyBy{7}); ``` +It's also fine for the callable to take no arguments, ignoring the arguments +supplied to the mock function: + +```cpp +MockFunction<int(int)> mock; +EXPECT_CALL(mock, Call).WillOnce([] { return 17; }); +EXPECT_EQ(mock.AsStdFunction()(0), 17); +``` + +When used with `WillOnce`, the callable can assume it will be called at most +once and is allowed to be a move-only type: + +```cpp +// An action that contains move-only types and has an &&-qualified operator, +// demanding in the type system that it be called at most once. This can be +// used with WillOnce, but the compiler will reject it if handed to +// WillRepeatedly. +struct MoveOnlyAction { + std::unique_ptr<int> move_only_state; + std::unique_ptr<int> operator()() && { return std::move(move_only_state); } +}; + +MockFunction<std::unique_ptr<int>()> mock; +EXPECT_CALL(mock, Call).WillOnce(MoveOnlyAction{std::make_unique<int>(17)}); +EXPECT_THAT(mock.AsStdFunction()(), Pointee(Eq(17))); +``` + +More generally, to use with a mock function whose signature is `R(Args...)` the +object can be anything convertible to `OnceAction<R(Args...)>` or +`Action<R(Args...)`>. The difference between the two is that `OnceAction` has +weaker requirements (`Action` requires a copy-constructible input that can be +called repeatedly whereas `OnceAction` requires only move-constructible and +supports `&&`-qualified call operators), but can be used only with `WillOnce`. +`OnceAction` is typically relevant only when supporting move-only types or +actions that want a type-system guarantee that they will be called at most once. + +Typically the `OnceAction` and `Action` templates need not be referenced +directly in your actions: a struct or class with a call operator is sufficient, +as in the examples above. But fancier polymorphic actions that need to know the +specific return type of the mock function can define templated conversion +operators to make that possible. See `gmock-actions.h` for examples. + #### Legacy macro-based Actions Before C++11, the functor-based actions were not supported; the old way of @@ -4244,7 +4234,7 @@ This implementation class does *not* need to inherit from any particular class. What matters is that it must have a `Perform()` method template. This method template takes the mock function's arguments as a tuple in a **single** argument, and returns the result of the action. It can be either `const` or not, -but must be invokable with exactly one template argument, which is the result +but must be invocable with exactly one template argument, which is the result type. In other words, you must be able to call `Perform<R>(args)` where `R` is the mock function's return type and `args` is its arguments in a tuple. @@ -4305,7 +4295,7 @@ particular type than to dump the bytes. ### Mock std::function {#MockFunction} `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, +preferred way of passing callbacks to new interfaces. Functions are copyable, and are not usually passed around by pointer, which makes them tricky to mock. But fear not - `MockFunction` can help you with that. |