Lines Matching +full:overloaded +full:- +full:virtual

12 actually mean very different things in the Test-Driven Development (TDD)
17     not suitable for production. An in-memory file system would be an example of
19 *   **Mocks** are objects pre-programmed with *expectations*, which form a
22 If all this seems too abstract for you, don't worry - the most important thing
46     error-prone. No wonder people go great distance to avoid it.
62 *   You are stuck with a sub-optimal design and wish you had done more
77     hand-written mocks.
93 relies on a [LOGO](http://en.wikipedia.org/wiki/Logo_programming_language)-like
97 shiny new graphics card that has better anti-aliasing? Suddenly you have to
107   virtual ~Turtle() {}
108   virtual void PenUp() = 0;
109   virtual void PenDown() = 0;
110   virtual void Forward(int distance) = 0;
111   virtual void Turn(int degrees) = 0;
112   virtual void GoTo(int x, int y) = 0;
113   virtual int GetX() const = 0;
114   virtual int GetY() const = 0;
118 (Note that the destructor of `Turtle` **must** be virtual, as is the case for
119 **all** classes you intend to inherit from - otherwise the destructor of the
132 because your new machine does anti-aliasing differently), easier to read and
140 class, relax - gMock turns this task into a fun game! (Well, almost.)
148 *   Take a *virtual* function of `Turtle` (while it's possible to
149     [mock non-virtual methods using templates](gmock_cook_book.md#MockingNonVirtualMethods),
152 *   Now comes the fun part: you take the function signature, cut-and-paste it
153     into the macro, and add two commas - one between the return type and the
157 *   Since you're overriding a virtual method, we suggest adding the `override`
159     for non-const methods just `(override)`. This isn't mandatory.
160 *   Repeat until all virtual functions you want to mock are done. (It goes
161     without saying that *all* pure virtual methods in your abstract class must
182 You don't need to define these mock methods somewhere else - the `MOCK_METHOD`
195 the same directory or a `testing` sub-directory), and put it in a `.h` and a
226 #include "path/to/mock-turtle.h"
303 If the method is not overloaded, the macro can also be called without matchers:
306 EXPECT_CALL(mock_object, non-overloaded-method)
315 overloaded.
336 Some people like to call this style of syntax a Domain-Specific Language (DSL).
375 [built-in matchers](reference/matchers.md) for common types (as well as
395 This works for all non-overloaded methods; if a method is overloaded, you need
408 An interesting special case is when we say `Times(0)`. You may have guessed - it
414 list of built-in cardinalities you can use, see
436 First, if the return type of a mock function is a built-in type or a pointer,
440 default-constructible (i.e. has a default constructor) has a default action of
441 returning a default-constructed value. If you don't say anything, this behavior
483 reference using `ReturnRef(`*`variable`*`)`, or invoke a pre-defined function,
484 among [others](gmock_cook_book.md#using-actions).
533 get an upper-bound-violated failure. Here's an example:
551 expectations in a mock object's constructor or the test fixture's set-up phase
558 **Tip:** It is very common to start with a catch-all expectation for a method
560 overloaded). This makes any calls to the method expected. This is not necessary
564 [Understanding Uninteresting vs Unexpected Calls](gmock_cook_book.md#uninteresting-vs-unexpected).
597 order as written. If a call is made out-of-order, it will be an error.
610 (solve it yourself first - don't cheat!):
641 for (int i = n; i > 0; i--) {
651 lead to an "upper bound violated" error - this piece of code is not very useful!
660 for (int i = n; i > 0; i--) {
687 it's in a sequence - as soon as another expectation that comes after it in the