Lines Matching +full:test +full:- +full:expectations

5 When you write a prototype or test, often it's not feasible or wise to rely on
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
35 2.  next, you create some mock objects and specify its expectations and behavior
38     violation to the expectations as soon as it arises.
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
69 *   You want to test how your code handles a failure (e.g. a file checksum
77     hand-written mocks.
93 relies on a [LOGO](http://en.wikipedia.org/wiki/Logo_programming_language)-like
94 API for drawing. How would you test that it does the right thing? Well, you can
97 shiny new graphics card that has better anti-aliasing? Suddenly you have to
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
133 maintain (the intent of a test is expressed in the code, not in some binary
140 class, relax - gMock turns this task into a fun game! (Well, almost.)
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
159     for non-const methods just `(override)`. This isn't mandatory.
182 You don't need to define these mock methods somewhere else - the `MOCK_METHOD`
190 `Foo` changes it, your test could break. (You can't really expect `Foo`'s
191 maintainer to fix every test that uses `Foo`, can you?)
195 the same directory or a `testing` sub-directory), and put it in a `.h` and a
215 3.  Specify your expectations on them (How many times will a method be called?
221     expectations on it have been satisfied.
226 #include "path/to/mock-turtle.h"
232 TEST(PainterTest, CanDrawSomething) {
243 As you might have guessed, this test checks that `PenDown()` is called at least
244 once. If the `painter` object didn't call this method, your test will fail with
256 **Tip 1:** If you run the test from an Emacs buffer, you can hit `<Enter>` on
264 **Important note:** gMock requires expectations to be set **before** the mock
267 any expectations on a mock after passing the mock to an API.
275 Admittedly, this test is contrived and doesn't do much. You can easily achieve
279 ## Setting Expectations
281 The key to using a mock object successfully is to set the *right expectations*
282 on it. If you set the expectations too strict, your test will fail as the result
284 to do it just right such that your test can catch exactly the kind of bugs you
306 EXPECT_CALL(mock_object, non-overloaded-method)
312 This syntax allows the test writer to specify "called with any arguments"
336 Some people like to call this style of syntax a Domain-Specific Language (DSL).
340 it makes expectations easily identifiable (either by `grep` or by a human
368 and can test whether an argument is what we'd expect. You can use a matcher
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
406 matcher can be. This allows a user to express the intent of a test exactly.
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).
523 ### Using Multiple Expectations {#MultiExpectations}  argument
526 realistically, you'll specify expectations on multiple mock methods which may be
529 By default, when a mock method is invoked, gMock will search the expectations in
533 get an upper-bound-violated failure. Here's an example:
550 expectations? The reason is that this allows a user to set up the default
551 expectations in a mock object's constructor or the test fixture's set-up phase
552 and then customize the mock by writing more specific expectations in the test
553 body. So, if you have two expectations on the same method, you want to put the
558 **Tip:** It is very common to start with a catch-all expectation for a method
562 useful for methods that have some expectations, but for which other calls are
564 [Understanding Uninteresting vs Unexpected Calls](gmock_cook_book.md#uninteresting-vs-unexpected).
570 order the expectations are specified.
578 TEST(FooTest, DrawsLineSegment) {
591 By creating an object of type `InSequence`, all expectations in its scope are
596 In this example, we test that `Foo()` calls the three expected functions in the
597 order as written. If a call is made out-of-order, it will be an error.
603 ### All Expectations Are Sticky (Unless Said Otherwise) {#StickyExpectations}  argument
606 How would you test that the turtle is asked to go to the origin *exactly twice*
610 (solve it yourself first - don't cheat!):
626 told you in the [Using Multiple Expectations](#MultiExpectations) section above.
628 This example shows that **expectations in gMock are "sticky" by default**, in
641 for (int i = n; i > 0; i--) {
649 said, expectations are sticky. So, the second time `turtle.GetX()` is called,
651 lead to an "upper bound violated" error - this piece of code is not very useful!
654 to explicitly say that the expectations are *not* sticky. In other words, they
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
698 it. If a call to this method occurs, you'll see a warning in the test output,