EasyMock

mock.resetToNice() causes all mocks that come from the same control to be reset to nice

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Not A Bug
  • Affects Version/s: 3.1
  • Fix Version/s: None
  • Component/s: Core
  • Labels:
  • Testcase included:
    yes
  • Number of attachments :
    0

Description

The test in the code below passes:

 
public class ControlFailTest {

    static interface Foo {
        void foo(String s);
    }

    static interface Bar {
        void bar(String s);
    }

    @Test
    public void testControlFail() {
        IMocksControl control = EasyMock.createControl();

        Foo foo = control.createMock(Foo.class);
        Bar bar = control.createMock(Bar.class);

        EasyMock.resetToNice(foo);

        control.replay();

        bar.bar("I'm not allowed!");

        control.verify();
    }

}

If I comment out the line which resets foo to nice, the test fails, as it should do.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Henri Tremblay added a comment -

foo and bar are linked to the same control. Resetting a mock means to reset its control.

So the behavior is expected. The control is resetted to nice.

Show
Henri Tremblay added a comment - foo and bar are linked to the same control. Resetting a mock means to reset its control. So the behavior is expected. The control is resetted to nice.
Hide
Permalink
Gleb Smirnov added a comment -

The documentation never says that changing the behavior of one mock causes the control's behavior to be changed, too. So, I guess it would be wise to state so explicitly in the manual.

Still, I do not find such behavior logical, and I suspect that to be a design fault.

Show
Gleb Smirnov added a comment - The documentation never says that changing the behavior of one mock causes the control's behavior to be changed, too. So, I guess it would be wise to state so explicitly in the manual. Still, I do not find such behavior logical, and I suspect that to be a design fault.
Hide
Permalink
Henri Tremblay added a comment -

I'll update the documentation. On the code side, the only possible thing would be to return an error when a mock created through a control is modified using a static method from the EasyMock class. That would mean remembering how a mock was created. It's not currently the case.

In your case, doing
Foo foo = EasyMock.createMock(Foo.class);
Bar bar = EasyMock.createMock(Bar.class);
EasyMock.resetToNice(foo);
EasyMock.replay(foo);

would work fine

Show
Henri Tremblay added a comment - I'll update the documentation. On the code side, the only possible thing would be to return an error when a mock created through a control is modified using a static method from the EasyMock class. That would mean remembering how a mock was created. It's not currently the case. In your case, doing Foo foo = EasyMock.createMock(Foo.class); Bar bar = EasyMock.createMock(Bar.class); EasyMock.resetToNice(foo); EasyMock.replay(foo); would work fine
Hide
Permalink
Gleb Smirnov added a comment -

I see what you mean, but that is still ideologically wrong: control can have effect on mocks that it has created, but not vice versa. I haven't really looked into the source code, but might well do. I guess, implementing proper behavior would be difficult given current architecture and whatnots.

Sure, I know that separating mocks and removing them from control would do, but that is sort of restricting.

Show
Gleb Smirnov added a comment - I see what you mean, but that is still ideologically wrong: control can have effect on mocks that it has created, but not vice versa. I haven't really looked into the source code, but might well do. I guess, implementing proper behavior would be difficult given current architecture and whatnots. Sure, I know that separating mocks and removing them from control would do, but that is sort of restricting.
Hide
Permalink
Henri Tremblay added a comment -

In fact, acting on a mock is just a shortcut to act on the control. It's the control that keeps the behavior. Creating multiple mocks on the same control is just a way to keep a coherent behavior a between the mocks. Like ordering the calls.

The mock is only a proxy to get to the control. But I can see why this can be misleading.

Show
Henri Tremblay added a comment - In fact, acting on a mock is just a shortcut to act on the control. It's the control that keeps the behavior. Creating multiple mocks on the same control is just a way to keep a coherent behavior a between the mocks. Like ordering the calls. The mock is only a proxy to get to the control. But I can see why this can be misleading.

People

  • Assignee:
    Henri Tremblay
    Reporter:
    Gleb Smirnov
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: