Rhino mock hangs when running 2 mocked methods in parallel (whenCalled stub)

115 views
Skip to first unread message

Ariel .b

unread,
Jul 7, 2015, 6:29:30 AM7/7/15
to rhino...@googlegroups.com

i'm doing a mocked test that waits until something finishes. the problem is ,that i can't run the 2nd method as it waits for the first one somehow.

public interface ITest
   {
       void T1();
       void T2();
   } 

the problem is in calling T2() - it waits for T1 to end. i don't understand why

[Test]
  public void TestThread()
  {
     ITest t = MockRepository.GenerateMock<ITest>();
     t.Stub(t1 => t1.T1()).WhenCalled((mi) =>
        {
           Thread.Sleep(10000);
        });

     t.Stub(t1 => t1.T2()).WhenCalled((mi) =>
     {
        // something
     });


     Task<string> task = Task.Factory.StartNew<string>(() =>
     {
        t.T1();
        return "";
     });

     Thread.Sleep(1000);
     t.T2(); // This hangs until T1 is finished!
  }

Anyone encountered this?

haifisch

unread,
Jul 8, 2015, 11:10:30 AM7/8/15
to rhino...@googlegroups.com
At the moment RhinoMocks doesn't allow parallel execution of methods on a single proxy instance (RhinoInterceptor.cs - line 65). However, if you remove the synchronization I fear that it might cause hard to spot side effects on complex threaded tests; but no unit tests on RhinoMocks currently fails if you remove the synchronization block - but a more sophisticated solution might be desirable. So if you have a patch please post a pull-request on https://github.com/alaendle/rhino-mocks.

bill richards

unread,
Jul 8, 2015, 12:16:28 PM7/8/15
to rhino...@googlegroups.com
I'm not entirely sure what this test achieves to be honest, other than testing parallel execution of methods on a single proxy instance (as haifisch mentions) as provided by Rhino

You have an interface which I imagine represents some dependency for your SUT (software under test)

Then you create your mock (which should be used to mock a dependency passed in to your SUT)

But then you attempt to get it involved in some threading stuff. Why would you want to do that?
         
Surely such a test belongs with the implementation of this interface (i.e. the class), I can foresee no reason to include such a thing in your tests.

Reply all
Reply to author
Forward
0 new messages