[mockitopp] r158 committed - Edited wiki page Argument_Matching through web user interface.

[mock...@googlecode.com]

Revision: 158
Author: plazt...@gmail.com
Date: Tue Jun 11 14:42:51 2013
Log: Edited wiki page Argument_Matching through web user interface.
http://code.google.com/p/mockitopp/source/detail?r=158

Modified:
/wiki/Argument_Matching.wiki

=======================================
--- /wiki/Argument_Matching.wiki Tue Jun 11 14:41:51 2013
+++ /wiki/Argument_Matching.wiki Tue Jun 11 14:42:51 2013
@@ -74,7 +74,7 @@

The `null<T>` matcher is an interesting one, in that one typically will
combine is with the `is_not()` modifier. This can be useful when the exact
pointer value being passed in is not reasonably known to the test due to
proper encapsulation -- it just needs to not be `NULL`.

-The second expectation set on our mocked instance of the `interface` type
uses the `any<T>` matcher. This is a way to say "we don't care what the
value is". This can be useful for focusing the reader of the test on what
is relevant to the given test. By over-specifying exact values for all
parameters to mocked methods, we are may be over-communicating and making
it harder to determine what's relevant to the exact scenario and action
(GivenWhenThen) versus others in the suite. Also, over-specification in
mocks can make them more brittle. When a regression occurs, more tests may
fail at once, creating noise for the developer to sift through. In
addition, over-specification can mean changes in the implementation that
require more tests and mock expectations need to be updated. So, keeping
tests and mock expectations focused on the "simplest thing that could
possible work" to pin down relevant behavior and protect against
regressions is highly recommended -- the `any<>` matcher is one of the
great tools to accomplish that. Keep in mind that even with the any<>
matcher, types need to implement `operater==()`; if they don't, you'll get
a compile error.
+The second expectation set on our mocked instance of the `interface` type
uses the `any<T>` matcher. This is a way to say "we don't care what the
value is". This can be useful for focusing the reader of the test on what
is relevant to the given test. By over-specifying exact values for all
parameters to mocked methods, we are may be over-communicating and making
it harder to determine what's relevant to the exact scenario and action
(GivenWhenThen) versus others in the suite. Also, over-specification in
mocks can make them more brittle. When a regression occurs, more tests may
fail at once, creating noise for the developer to sift through. In
addition, over-specification can mean changes in the implementation that
require more tests and mock expectations need to be updated. So, keeping
tests and mock expectations focused on the "simplest thing that could
possible work" to pin down relevant behavior and protect against
regressions is highly recommended -- the `any<>` matcher is one of the
great tools to accomplish that. Keep in mind that even with the any<>
matcher, types need to implement `operator==()`; if they don't, you'll get
a compile error.

The third expectation uses the `equal<>` matcher, combined with the
`is_not()` modifier. Note that the template parameter, `const
std::string&`, matches the `interface::func2` signature *exactly*. If there
is even a slight mismatch -- a missing const, value instead of reference,
etc -- then a compile error will occur. Also, if the type supplied in the
`thenReturn()` clause does not match the mocked method signature, you will
get a similar compile error.