Как проверить ViewModel, который загружается с помощью BackgroundWorker? - PullRequest
Новая
       10

Как проверить ViewModel, который загружается с помощью BackgroundWorker?

13 голосов
/ 23 июня 2011

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

public class MyViewModel
{
    public DelegateCommand LoadDataCommand { get; set; }

    private List<Data> myData;
    public List<Data> MyData
    {
        get { return myData; }
        set { myData = value; RaisePropertyChanged(() => MyData); }
    }

    public MyViewModel()
    {
        LoadDataCommand = new DelegateCommand(OnLoadData);
    }

    private void OnLoadData()
    {
        // loads data over wcf or db or whatever. doesn't matter from where...
        MyData = wcfClient.LoadData();
    }
}

[TestMethod]
public void LoadDataTest()
{
    var vm = new MyViewModel();
    vm.LoadDataCommand.Execute();
    Assert.IsNotNull(vm.MyData);
}

Так что это все довольно просто. Однако я действительно хотел бы загрузить данные, используя BackgroundWorker, и вывести на экран сообщение «загрузка». Поэтому я изменил ВМ на: 

private void OnLoadData()
{
    IsBusy = true; // view is bound to IsBusy to show 'loading' message.

    var bg = new BackgroundWorker();
    bg.DoWork += (sender, e) =>
    {
      MyData = wcfClient.LoadData();
    };
    bg.RunWorkerCompleted += (sender, e) =>
    {
      IsBusy = false;
    };
    bg.RunWorkerAsync();
}

Это отлично работает визуально во время выполнения, однако мой тест теперь не проходит из-за того, что свойство не загружается сразу. Может кто-нибудь предложить хороший способ проверить этот вид загрузки? Я полагаю, что мне нужно что-то вроде: 

[TestMethod]
public void LoadDataTest()
{
    var vm = new MyViewModel();
    vm.LoadDataCommand.Execute();

    // wait a while and see if the data gets loaded.
    for(int i = 0; i < 10; i++)
    {
        Thread.Sleep(100);
        if(vm.MyData != null)
            return; // success
    }
    Assert.Fail("Data not loaded in a reasonable time.");
}

Однако это кажется действительно неуклюжим ... Это работает, но просто кажется грязным. Есть лучшие предложения?

Возможное решение :

Основываясь на ответе Дэвида Холла, чтобы смоделировать BackgroundWorker, я закончил делать эту довольно простую оболочку вокруг BackgroundWorker, которая определяет два класса, один загружает данные асинхронно, а другой загружает синхронно. 

  public interface IWorker
  {
    void Run(DoWorkEventHandler doWork);
    void Run(DoWorkEventHandler doWork, RunWorkerCompletedEventHandler onComplete);
  }

  public class AsyncWorker : IWorker
  {
    public void Run(DoWorkEventHandler doWork)
    {
      Run(doWork, null);
    }

    public void Run(DoWorkEventHandler doWork, RunWorkerCompletedEventHandler onComplete)
    {
      var bg = new BackgroundWorker();
      bg.DoWork += doWork;
      if(onComplete != null)
        bg.RunWorkerCompleted += onComplete;
      bg.RunWorkerAsync();
    }
  }

  public class SyncWorker : IWorker
  {
    public void Run(DoWorkEventHandler doWork)
    {
      Run(doWork, null);
    }

    public void Run(DoWorkEventHandler doWork, RunWorkerCompletedEventHandler onComplete)
    {
      Exception error = null;
      var args = new DoWorkEventArgs(null);
      try
      {
        doWork(this, args);
      }
      catch (Exception ex)
      {
        error = ex;
        throw;
      }
      finally
      {
        onComplete(this, new RunWorkerCompletedEventArgs(args.Result, error, args.Cancel));
      }
    }
  }

Итак, в моей конфигурации Unity я могу использовать SyncWorker для тестирования и AsyncWorker для производства. Моя ViewModel становится: 

public class MyViewModel(IWorker bgWorker)
{
    public void OnLoadData()
    {
        IsBusy = true;
        bgWorker.Run(
          (sender, e) =>
          {
            MyData = wcfClient.LoadData();
          },
          (sender, e) =>
          {
            IsBusy = false;
          });
    }
}

Обратите внимание, что вещь, которую я пометил как wcfClient, на самом деле тоже является Мок в моих тестах, поэтому после вызова vm.LoadDataCommand.Execute() я также могу проверить, что wcfClient.LoadData() был вызван.

Ответы [ 2 ]

13 голосов
/ 23 июня 2011

Представьте себе фиктивного / поддельного фонового работника, который проверяет, что вы правильно его вызываете, но немедленно возвращает с готовым ответом.

Измените модель представления, чтобы разрешить внедрение зависимостей, либо путем внедрения свойства, либо путем внедрения конструктораЯ покажу инъекцию конструктора ниже), а затем при тестировании вы переходите в поддельный фоновый рабочий.В реальном мире вы внедряете реальную реализацию при создании виртуальной машины. 

public class MyViewModel
{
    private IBackgroundWorker _bgworker;

    public MyViewModel(IBackgroundWorker bgworker)
    {
        _bgworker = bgworker;
    }

    private void OnLoadData()    
    {        
        IsBusy = true; // view is bound to IsBusy to show 'loading' message.        

        _bgworker.DoWork += (sender, e) =>        
        {          
            MyData = wcfClient.LoadData();        
        };        
        _bgworker.RunWorkerCompleted += (sender, e) =>        
        {          
            IsBusy = false;        
        };        
        _bgworker.RunWorkerAsync();    
    }

}

В зависимости от вашей структуры (Unity / Prism в вашем случае) подключение правильного фонового работника не должно быть слишком сложным.

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

0 голосов
/ 20 ноября 2012

Вы можете избежать дополнительной абстракции, если хотите обменять ее на небольшое загрязнение модели представления (т. Е. Ввести код, который используется только для ваших тестов) следующим образом:

Сначала добавьте необязательный параметр AutoResetEvent (или ManualResetEvent) в конструктор модели представления и убедитесь, что вы «установили» этот экземпляр AutoResetEvent, когда ваш фоновый работник завершает обработчик «RunWorkerCompleted». 

public class MyViewModel {   
  private readonly BackgroundWorker _bgWorker;
  private readonly AutoResetEvent _bgWorkerWaitHandle;

  public MyViewModel(AutoResetEvent bgWorkerWaitHandle = null) {
    _bgWorkerWaitHandle = bgWorkerWaitHandle;

    _bgWorker = new BackgroundWorker();
    _bgWorker.DoWork += (sender, e) => {          
      //Do your work
    };        
    _bgworker.RunWorkerCompleted += (sender, e) => {          
      //Configure view model with results

      if (_bgWorkerWaitHandle != null) {
         _bgWorkerWaitHandle.Set();
      }
    };
    _bgWorker.RunWorkerAsync();
  }
}

Теперь вы можете передать экземпляр как часть вашего модульного теста. 

[Test]
public void Can_Create_View_Model() {
  var bgWorkerWaitHandle = new AutoResetEvent(false); //Make sure it starts off non-signaled
  var viewModel = new MyViewModel(bgWorkerWaitHandle);
  var didReceiveSignal = bgWorkerWaitHandle.WaitOne(TimeSpan.FromSeconds(5));
  Assert.IsTrue(didReceiveSignal, "The test timed out waiting for the background worker to complete.");
  //Any other test assertions
}

Это именно то, для чего были разработаны классы AutoResetEvent (и ManualResetEvent). Таким образом, кроме небольшого загрязнения кода модели представления, я думаю, что это решение довольно опрятно.

...