Rhino издевается над методом юнит-тестирования - PullRequest
Новая
       9

Rhino издевается над методом юнит-тестирования

1 голос
/ 20 ноября 2011

Я новичок в издевательствах над носорогом и юнит-тестировании в целом.Я начинаю писать некоторые тесты для моего приложения wpf mvvm.Вот пример сценария, который я пытаюсь проверить:

Модель представления: 

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;
   }
}

Сервер: 

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

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

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

В моем тесте я хочу убедиться, чтоviewModel.VMData.Count == server.TheData.Count.Я попытался использовать насмешки на носорогов, чтобы заглушить сервер, предварительно добавив в TheData некоторые значения.Я вызвал конструктор модели представления, а затем попытался сравнить счетчики.

Моя проблема в том, что я не знаю, как заставить мой сервер действительно перезвонить в мою модель представления.После вызова конструктора vm метод InitializeData () вызывается, как и ожидалось, но вызов GetData сервера-заглушки не выполняется.

Как заставить этот простой тест работать?

1 Ответ

0 голосов
/ 01 декабря 2011

если вы заглушаете IServer и ожидаете, что вызов метода в заглушке вызовет реализацию в вашем конкретном классе, это ваше заблуждение. метод GetData в экземпляре-заглушке будет возвращать только то, что вы ему сказали, и не будет выполнять какой-либо код в конкретной зависимости. помните, что единственное, что ваш заглушка IServer-объект имеет общего с вашей конкретной реализацией IServer, это то, что они оба реализуют IServer. ожидая, что побочные эффекты в методе в вашей конкретной реализации произойдут, когда вызов метода на заглушке просто неисправен.

о том, как заставить его работать: на самом деле нет хорошего способа сделать этот тест, поскольку вы заявляете, что дизайн этих классов как есть. Вы пытаетесь проверить, что побочный эффект произошел в зависимости, которую вы заглушаете от участия. чтобы действительно протестировать то, что вы хотите здесь, и если вы хотите сохранить эти классы с такими отношениями, я бы посоветовал вам вообще не издеваться над сервером и использовать реальный объект. Перепроектируйте сервер так, чтобы он зависел от другого компонента, который загружается из кэша, чтобы вы могли вместо этого заглушить его.

...