Question

I am new to rhino mocks and unit testing in general. I am starting to write some tests for my wpf mvvm app. Here is a sample scenario I am trying to test:

The view model:

List<DataItems> _theData = new List<DataItems>();
public MyViewModel(IServer server)
{
  _server = server;
  InitializeData();
}

private void InitializeData()
{
  _server.GetData(MyCallback);
}

private void MyCallback()
{
  _theData = _server.TheData;
}

public List<DataItems> VMData
{
   get
   {
     return _theData;
   }
}

Server:

public List<DataItems> TheData
{
  get
  {
    return _cachedData;
  }
}

public void GetData(Action callBack)
{
  //Populate cached data
  ...

  if(callBack != null)
  {
    callBack();
  }
}

In my test, I want to verify that viewModel.VMData.Count == server.TheData.Count. I tried using rhino mocks to stub the server, pre-poulating TheData with some values. The I called the view model constructor, and then tried to compare the counts.

My problem is that I do not know how to get my server to actually call back into my view model. After the vm constructor is called, InitializeData() is called as expected but the stub server’s GetData call is not made.

How can I make this simple test work?

Answer 1

if you are stubbing IServer and expecting that the calling a method on the stub will invoke the implementation in your concrete class, that is your misconception. the GetData method on the stub instance will only return what you tell it to, and not execute any code in the concrete dependency. remember that the only thing your stub IServer object has in common with your concrete implemetation of IServer is that they both implement IServer. expecting that the side effects in the method in your concrete implemenation will happen when calling the method on the stub is just faulty.

as to how to make it work: there’s not really a good way to do this test as you are stating with the design of these classes as is. you are trying to test that a side effect occurred in the dependency that you are stubbing out of participation. to really test what you want here and if you want to keep these classes with this relationship, i’d suggest that you don’t mock server at all and use the real object. redesign the server so that it depends on another component that loads from the cache so you can stub that thing instead.