EasyMock
  1. EasyMock
  2. EASYMOCK-109

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

        Hide
        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
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: