Support needed for actions created from class methods that have more parameters than mock function parameters
Closed this issue · 4 comments
GoogleCodeExporter commented
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Revision 174. Linux.
Please provide any additional information below.
Suppose I have the following example:
class MyMock
{
public:
MOCK_METHOD2(mockMethod, void(bool));
};
class Tester
{
public:
void myAction(bool b, int n)
{
h1.doSth();
h2.doSth();
//use b
//use n;
}
private:
Helper1 h1;
Helper2 h2;
};
Now I want to use myAction as action for mockMethod() (just like ACTION_Pk
family but based on methods in class).
I doubt it is possible in current gmock.
The idea comes from the fact it is uncomfortable to pass multiple objects
needed to implement complex actions as parameters to ACTION_Pk that are
kept in Tester class. So I would like to use Tester methods to make
actions. However I cannot pass additional parameters as I could in
ACTION_Pk case.
Original issue reported on code.google.com by prez...@gmail.com
on 18 Feb 2010 at 11:54
GoogleCodeExporter commented
One idea to implement this would be to have mechanism similar to boost function:
Tester t;
MyMock m;
Action<void (bool)> a = testing::Bind(&t, &Tester::myAction, _1, 7);
EXPECT_CALL(m, mockMethod(_)).WillOnce(a);
Original comment by prez...@gmail.com
on 18 Feb 2010 at 12:01
GoogleCodeExporter commented
So why not
Tester t;
MyMock m;
EXPECT_CALL(m, mockMethod(_))
.WillOnce(testing::Invoke(boost::bind(&Tester::myAction, &t, _1, 7)));
?
Original comment by vladlosev
on 19 Feb 2010 at 1:13
- Added labels: Type-Enhancement
- Removed labels: Type-Defect
GoogleCodeExporter commented
Write this once:
ACTION_P2(DoMyAction, tester, n) { return tester->myAction(arg0, n); }
Then you can use it many times, with a more readable syntax:
...WillOnce(DoMyAction(&t, 7));
We *could* define Bind() for actions, but I'm not sure how often it's needed,
and I
don't want to reinvent tr1 bind given that it will be part of the STL soonish.
Original comment by w...@google.com
on 19 Feb 2010 at 7:10
- Changed state: Accepted
- Added labels: OpSys-All, Priority-Low, Usability
- Removed labels: Priority-Medium
GoogleCodeExporter commented
We don't intend to reinvent bind.
Original comment by w...@google.com
on 6 Mar 2010 at 5:42
- Changed state: WontFix