hokanos / googlemock Goto Github PK

Currently ON_CALL() and EXPECT_CALL() accepts a
.WithArguments(tuple_matcher) clause for specifying constraints on multiple
arguments, but it's not very easy to use.  The proposal:

- Allow optional template arguments to select the function arguments that
will participate in the matching, ala the WithArgs(callable) action.
- Allow the clause to be used more than once in an expectation.

For example,

  ON_CALL(foo, Bar(_, _, _))
      .WithArguments(A())
      .WithArguments<0, 2>(B())
      .WithArguments<2, 1>(C());

says that:

  - argument 0, 1, and 2 should match matcher A(),
  - argument 0 and 2 should match matcher B(), and
  - argument 2 and 1 should match matcher C().

One use case is that often a function passes a pointer to a buffer in one
argument and the size of the buffer in another argument, and we may want to
verify that the contents of the buffer are expected.

Currently ON_CALL() and EXPECT_CALL() accepts a
.WithArguments(tuple_matcher) clause for specifying constraints on multiple
arguments, but it's not very easy to use.  The proposal:

- Allow optional template arguments to select the function arguments that
will participate in the matching, ala the WithArgs(callable) action.
- Allow the clause to be used more than once in an expectation.

For example,

  ON_CALL(foo, Bar(_, _, _))
      .WithArguments(A())
      .WithArguments<0, 2>(B())
      .WithArguments<2, 1>(C());

says that:

  - argument 0, 1, and 2 should match matcher A(),
  - argument 0 and 2 should match matcher B(), and
  - argument 2 and 1 should match matcher C().

One use case is that often a function passes a pointer to a buffer in one
argument and the size of the buffer in another argument, and we may want to
verify that the contents of the buffer are expected.

Compare googlemock with the following frameworks such that the users know
which one to use:

mockpp: http://mockpp.sourceforge.net/
mockcpp: http://code.google.com/p/mockcpp/
mockitopp: http://code.google.com/p/mockitopp/
amop: http://code.google.com/p/amop/

Leveraging Google Mock as a subdirectory package via Autotools (likely a
common configuration) requires quite a bit of manual setup for the client
project, the vast majority of which will be identical with every other
client project. We should provide a M4-based macro that not only can
leverage an installed copy of Google Mock, but can automate some (if not
all) of the process of configuring and building Google Mock as a subdir
package with Autotools.

Bug Neal Norwitz to make his mock generator script available.