[mockitopp] r146 committed - Misc. cleanup

[mock...@googlecode.com]

Revision: 146
Author: trevor...@gmail.com
Date: Sat Sep 29 00:20:38 2012
Log: Misc. cleanup
http://code.google.com/p/mockitopp/source/detail?r=146

Modified:
/wiki/Stubbing.wiki

=======================================
--- /wiki/Stubbing.wiki Tue Nov 29 05:05:50 2011
+++ /wiki/Stubbing.wiki Sat Sep 29 00:20:38 2012
@@ -1,24 +1,23 @@
#labels Featured
<wiki:toc max_depth="3" />

-= Simple Example =
-This example is trivial but shows the basics for constructing a simple
mock of an interface and stubbing its only virtual function. Note that even
methods returning void *require* a .thenReturn() to punctuate the mock
expectation. If you don't, you'll experience a crash or other sub-optimal
behavior. (In VC++, you'll get a crash in the bowels of std::list, for
instance.)
+= Basics =
+The following example shows howto construct a simple mock of an interface,
stubbing a _zero_ argument _void_ function.
+
+*Note:* Be sure to always include the .when() and .thenReturn() clauses to
provide a complete stubbing. Failure to do so may result in an unexpected
crash and/or undesirable behavior.

{{{
-#include <gtest/gtest.h>
#include <mockitopp/mockitopp.hpp>

-// some interface
-struct Foo
-{
+// interface
+struct Foo {
virtual void bar() = 0;
};

-// a simple test case
-TEST(MyTestCase, Foo)
-{
+// test
+TEST(BasicExample) {
mockitopp::mock_object<Foo> mock;
- mock(&Foo::bar).thenReturn();
+ mock(&Foo::bar).when().thenReturn();
Foo& fooImpl = mock.getInstance();

ASSERT_NO_THROW(fooImpl.bar());
@@ -28,17 +27,15 @@
= Returnable Behavior =
This example shows how you can define simple returnable behavior for an
object. You will notice that we chained a bunch of arguments and their
return values together in a nice readable format. We then have our
associated gtest {{{ASSERT_?}}} macros verify the expected behavior. As you
can see we make a call to {{{adderImpl.add(4, 5)}}}, but we didn't define
any behavior for it. What happens in this case is the stub implementation
will try to return the default behavior for function's signature. This
means for POD (i.e. {{{int}}}, {{{bool}}}, etc.) it will return 0, false,
0.0, etc. For objects it will try to return the object using the default
constructor (i.e. {{{std::string()}}}, {{{std::vector()}}}, etc). For
pointers it will return {{{NULL}}}. For reference types it will do a very
dangerous cast from a pointer to a primitive to a reference of the return
type (which may or may not be desired, SO BE CAREFUL).
{{{
-#include <gtest/gtest.h>
#include <mockitopp/mockitopp.hpp>

-// some interface
-struct Adder
-{
+// interface
+struct Adder {
virtual int add(int a, int b) = 0;
};

-// test case
-TEST(MyTestCase, Adder)
+// test
+TEST(ReturnableTest)
{
mockitopp::mock_object<Adder> mock;
mock(&Adder::add).when(0, 0).thenReturn(0);
@@ -46,38 +43,35 @@
mock(&Adder::add).when(2, 2).thenReturn(5); // most certainly 2 + 2 = 5!
Adder& adderImpl = mock.getInstance();

- ASSERT_EQ(adderImpl.add(0, 0), 0);
- ASSERT_EQ(adderImpl.add(1, 1), 2);
- ASSERT_EQ(adderImpl.add(2, 2), 5);
+ ASSERT_EQUAL(adderImpl.add(0, 0), 0);
+ ASSERT_EQUAL(adderImpl.add(1, 1), 2);
+ ASSERT_EQUAL(adderImpl.add(2, 2), 5);
// What does 4 + 5 return?
// We didn't define any behavior!!!
- ASSERT_EQ(adderImpl.add(4, 5), 0);
+ ASSERT_EQUAL(adderImpl.add(4, 5), 0);
}
}}}

= Throwable Behavior =
This example shows how you can define simple throwable behavior for an
object. Similarly to the returnable action behavior you can instead decide
to use {{{thenThrow(...)}}} to define a throwable action. AS you may have
noticed you can chain together multiple throwable and returnable actions.
This is useful for cases where your mock object is only expected to handle
certain argument types.
{{{
-#include <gtest/gtest.h>
#include <mockitopp/mockitopp.hpp>

-// some interface
-struct Adder
-{
+// interface
+struct Adder {
virtual int add(int a, int b) = 0;
};

-// test case
-TEST(MyTestCase)
-{
+// test
+TEST(ThrowableTest) {
mockitopp::mock_object<Adder> mock;
mock(&Adder::add).when(0, 0).thenReturn(0)
mock(&Adder::add).when(1, 1).thenReturn(2)
mock(&Adder::add).when(2, 2).thenThrow(std::string("I don't support
this!")); // Don't believe me? I dare you to try it!
Adder& adderImpl = mock.getInstance();

- ASSERT_EQ(adderImpl.add(0, 0), 0);
- ASSERT_EQ(adderImpl.add(1, 1), 2);
+ ASSERT_EQUAL(adderImpl.add(0, 0), 0);
+ ASSERT_EQUAL(adderImpl.add(1, 1), 2);
ASSERT_THROW(int result = adderImpl.add(2, 2), std::string);
}
}}}
@@ -87,18 +81,15 @@

What happens when you don't stub behavior for a given input? In this case
it operates as if you stubbed the argument using the {{{thenReturn}}}
method.
{{{
-#include <gtest/gtest.h>
#include <mockitopp/mockitopp.hpp>

-// some interface
-struct Foo
-{
+// interface
+struct Foo {
virtual void bar(int x) = 0;
};

-// test case
-TEST(MyTestCase)
-{
+// test
+TEST(VoidFunctionTest) {
mockitopp::mock_object<Foo> mock;
mock(&Foo::bar).when(0).thenReturn();
mock(&Foo::bar).when(1).thenReturn();
@@ -112,20 +103,18 @@
}
}}}

-= Iterator-Style =
+= Iterator Style =
You can stub arguments to return different values on consecutive calls.
This is useful for modeling iterator like behavior for a given argument
list. It even works with a function that takes no arguments. The
configuration is similar to the previous uses except you chain together
consecutive calls to the {{{thenReturn}}} and {{{thenThrow}}} methods from
a single call to the {{{when}}} method. Also, the last stubbed
{{{thenReturn}}} or {{{thenThrow}}} becomes the default behavior on
consecutive calls after the the last element is hit.
{{{
-#include <gtest/gtest.h>
#include <mockitopp/mockitopp.hpp>

-// some interface
-struct Enumeration
-{
+// interface
+struct Enumeration {
virtual int next() = 0;
};

-// test case
-TEST(MyTestCase, Enumeration)
+// test
+TEST(IteartorTest)
{
mockitopp::mock_object<Enumeration> mock;
mock(&Enumeration::next).when().thenReturn(0)
@@ -135,24 +124,22 @@
.thenReturn(3);
Enumeration& e = mock.getInstance();

- ASSERT_EQ(0, e.next()); // should return 0
- ASSERT_EQ(1, e.next()); // should return 1
+ ASSERT_EQUAL(0, e.next()); // should return 0
+ ASSERT_EQUAL(1, e.next()); // should return 1
ASSERT_THROW(1 == e.next(), std::string); // should throw an exception
- ASSERT_EQ(2, e.next()); // should return 2
- ASSERT_EQ(3, e.next()); // should return 3
- ASSERT_EQ(3, e.next()); // remaining consecutive calls return the last
stubbed value
+ ASSERT_EQUAL(2, e.next()); // should return 2
+ ASSERT_EQUAL(3, e.next()); // should return 3
+ ASSERT_EQUAL(3, e.next()); // remaining consecutive calls return the
last stubbed value
}
}}}

= Overloaded Functions =
In some cases an interface may have several overloaded functions. The
mocking behavior is similar to the other examples but requires an extra
step for resolving the overloaded function. There are currently two ways in
which you can resolve the member function pointer: {{{(1)}}} define an
intermediate variable acting as a proxy for the lookup, or {{{(2)}}} use
the static_cast operator to provide the compiler lookup. Unfortunately,
both ways are a little bit more verbose but are required for the compiler
to resolve the functions properly.
{{{
-#include <gtest/gtest.h>
#include <mockitopp/mockitopp.hpp>

-// overloaded interface
-struct OverloadedInterface
-{
+// interface
+struct OverloadedInterface {
virtual void foo() = 0;
virtual void foo(int) = 0;
virtual void foo(std::string) = 0;