dvdvorle
dvdvorle

Reputation: 961

Mocking a blocking call with Rhino Mocks

I'm currently building a class using TDD. The class is responsible for waiting for a specific window to become active, and then firing some method.

I'm using the AutoIt COM library (for more information about AutoIt look here) since the behavior I want is actually a single method in AutoIt.

The code is pretty much as the following:

public class WindowMonitor
{
    private readonly IAutoItX3 _autoItLib;

    public WindowMonitor(IAutoItX3 autoItLib)
    {
        _autoItLib = autoItLib;
    }


    public void Run() // indefinitely
    {
        while(true)
        {
            _autoItLib.WinWaitActive("Open File", "", 0);
            // Do stuff now that the window named "Open File" is finally active.
        }
    }
}

As you can see the AutoIt COM library implements an interface wich I can mock (Using NUnit and Rhino Mocks):

[TestFixture]
 public class When_running_the_monitor
 {
  WindowMonitor subject;
  IAutoItX3 mockAutoItLibrary;
  AutoResetEvent continueWinWaitActive;
  AutoResetEvent winWaitActiveIsCalled;


 [SetUp]
 public void Setup()
  {
   // Arrange
   mockAutoItLibrary = MockRepository.GenerateStub<IAutoItX3>();
   mockAutoItLib.Stub(m => m.WinWaitActive("", "", 0))
                .IgnoreArguments()
                .Do((Func<string, string, int, int>) ((a, b, c) =>
                {
                    winWaitActiveIsCalled.Set();
                    continueWinWaitActive.WaitOne();
                    return 1;
                }));

   subject = new Subject(mockAutoItLibrary)

   // Act
   new Thread(new ThreadStart(subject.Run)).Start();
   winWaitActiveIsCalled.WaitOne();
  }

  // Assert

    [Test]
    [Timeout(1000)]
    public void should_call_winWaitActive()
    {
        mockAutoItLib.AssertWasCalled(m => m.WinWaitActive("Bestand selecteren", "", 0));
    }

    [Test]
    [Timeout(1000)]
    public void ensure_that_nothing_is_done_while_window_is_not_active_yet()
    {
        // When you do an "AssertWasCalled" for the actions when the window becomes active, put an equivalent "AssertWasNotCalled" here.

    }

}

The problem is, the first test keeps timing out. I have already found out that when the stub "WinWaitActive" is called, it blocks (as intended, on the seperate thread), and when the "AssertWasCalled" is called after that, execution never returns.

I'm at a loss how to proceed, and I couldn't find any examples of mocking out a blocking call.

So in conclusion:

Is there a way to mock a blocking call without making the tests timeout?

(P.S. I'm less interested in changing the design (i.e. "Don't use a blocking call") since it may be possible to do that here, but I'm sure there are cases where it's a lot harder to change the design, and I'm interested in the more general solution. But if it's simply impossible to mock blocking calls, suggestions like that are more that welcome!)

Upvotes: 1

Views: 1559

Answers (2)

Stefan Steinegger
Stefan Steinegger

Reputation: 64628

Not sure if I understand the problem.

Your code is just calling a method on the mock (WinWaitActive). Of course, it can't proceed before the call returns. This is in the nature of the programming language and nothing you need to test.

So if you test that WinWaitActive gets called, your test is done. You could test if WinWaitActive gets called before anything else, but this requires ordered expectations, which requires the old style rhino mocks syntax and is usually not worth to do.

   mockAutoItLibrary = MockRepository.GenerateStub<IAutoItX3>();

   subject = new Subject(mockAutoItLibrary)
   subject.Run()

   mockAutoItLib.AssertWasCalled(m => m.WinWaitActive("Open File", "", 0));

You don't do anything else then calling a method ... so there isn't anything else to test.

Edit: exit the infinite loop

You could make it exit the infinite loop by throwing an exception from the mocks. This is not very nice, but it avoids having all this multi-threading stuff in the unit test.

   mockAutoItLibrary = MockRepository.GenerateStub<IAutoItX3>();

   // make loop throw an exception on second call
   // to exit the infinite loop
   mockAutoItLib
     .Stub(m => m.WinWaitActive(
       Arg<string>.Is.Anything, 
       Arg<string>.Is.Anything, 
       Arg<int>.Is.Anything));
     .Repeat.Once();

   mockAutoItLib
     .Stub(m => m.WinWaitActive(
       Arg<string>.Is.Anything, 
       Arg<string>.Is.Anything, 
       Arg<int>.Is.Anything));
     .Throw(new StopInfiniteLoopException());

   subject = new Subject(mockAutoItLibrary)
   try
   {
     subject.Run()
   }
   catch(StopInfiniteLoopException)
   {} // expected exception thrown by mock

   mockAutoItLib.AssertWasCalled(m => m.WinWaitActive("Open File", "", 0));

Upvotes: 3

Joseph Tanenbaum
Joseph Tanenbaum

Reputation: 2241

Your Test only contains a call to the mocked method. Therefore it tests only your mock instead of any real code, which is an odd thing to do. We might need a bit more context to understand the problem.

Use Thread.Sleep() instead of AutoResetEvents: Since you are mocking the COM object that does the blocking window-active check, you can just wait for some time to mimick the behavior, and then make sure that the window is indeed active by making it active programmatically. How you block should not be important in the test, only that you block for some significant time.

Although from your code it is not clear how winWaitActiveIsCancelled and continueWinWaitActive contribute, I suspect they should be left out of the WinWaitActive mock. Replace them with a Thread.Sleep(500).

Upvotes: 1

Related Questions