add a recipe on how to do something N times followed by something else M times

[GoogleCodeExporter]

What steps will reproduce the problem?
None

What is the expected output? What do you see instead?
None

What version of the product are you using? On what operating system?
Revision 174

Please provide any additional information below.
I am missing the following functionality in gmock library:

EXPECT_CALL(mock, mockMethod(_)).WillNTimes(i, doSth1()).WillNTimes(j,
doSth2());

that will i times do doSth1() and next j times doSth2().

I even implemented a simple piece of code that achieves it through
repetitive usage of WillOnce():

  Expectation& WillNTimes(unsigned int callCount, const Action<F>& action) {
    for (unsigned int i = 0; i < callCount; ++i) {
      this->WillOnce(action);
    }
    return *this;
  }

Can you please consider implementing such function (or just include my
snippet if you find it OK?)

Original issue reported on code.google.com by prez...@gmail.com on 25 Jun 2009 at 1:12

[GoogleCodeExporter]

prezess, the snippet you gave uses testing::internal::Expectation.  As
the namespace suggests, this is an internal class and not officially
supported.  It will change in the future.  In fact, it has already
changed if you sync to the trunk head.  Therefore a user shouldn't use
it directly.

What you can do is:

  InSequence s;
  EXPECT_CALL(mock, mockMethod(_))
      .Times(i)
      .WillRepeatedly(doSth1());
  EXPECT_CALL(mock, mockMethod(_))
      .Times(j)
      .WillRepeatedly(doSth2());

Therefore we don't strictly need a new construct.  I'll write a recipe
about this in the cookbook instead.  Thanks.

Original comment by zhanyong...@gmail.com on 16 Jul 2009 at 7:43

• Changed title: add a recipe on how to do something N times followed by something else M times
• Changed state: Accepted
• Added labels: Type-Enhancement, Priority-Low, OpSys-All, Usability, Component-Docs
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

WillNTimes() was supposed to become a part of Expectation class interface. I 
didn't
want to use it externally. However, indeed it is not essential as can be 
replaced by
sequence of expectations. The only drawback of your approach is that 
declaration of s
variable forces placement of EXPECT_CALL invocation for different methods, 
doesn't it?
Anyways you may reconsider addition of convenience method I proposed to 
Expectation
class. Thanks.

Original comment by prez...@gmail.com on 16 Jul 2009 at 9:07