Prawidłowa metoda korzystania z programu rozsyłającego WPF w testach jednostkowych

Question

Próbuję wykonać sugestie od Using the WPF Dispatcher in unit tests, aby uruchomić test nUnit.

Kiedy piszę badanej jednostki, jak poniżej, to działa:

[Test] 
public void Data_Should_Contain_Items() 
{ 
    DispatcherFrame frame = new DispatcherFrame(); 
     PropertyChangedEventHandler waitForModelHandler = delegate(object sender, PropertyChangedEventArgs e) 
     { 
      if (e.PropertyName == "Data") 
      { 
      frame.Continue = false; 
      } 
     }; 
    _myViewModel.PropertyChanged += waitForModelHandler; 
    Dispatcher.PushFrame(frame); 

    Assert.IsTrue(_myViewModel.Data.Count > 0, "Data item counts do not match"); 
} 

Jednakże jeśli próbuję użyć sugestię DispatcherUtil, to nie działa:

[Test] 
public void Data_Should_Contain_Items() 
{ 
    DispatcherUtil.DoEvents(); 
    Assert.IsTrue(_myViewModel.Data.Count > 0, "Data item counts do not match"); 
} 

public static class DispatcherUtil 
{ 
    [SecurityPermissionAttribute(SecurityAction.Demand, Flags = SecurityPermissionFlag.UnmanagedCode)] 
    public static void DoEvents() 
    { 
     DispatcherFrame frame = new DispatcherFrame(); 
     Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background, 
      new DispatcherOperationCallback(ExitFrame), frame); 
     Dispatcher.PushFrame(frame); 
    } 

    private static object ExitFrame(object frame) 
    { 
     ((DispatcherFrame)frame).Continue = false; 
     return null; 
    } 
} 

Kiedy Korzystam z DispatcherUtil, wygląda na to, że wywołanie ExitFrame dzieje się zbyt wcześnie, zanim dane są gotowe.

Czy nie używam poprawnie narzędzia DispatcherUtil? Wydaje się, że jest to lepsza metoda do obsługi dyspozytora niż czekania na wywołania zwrotne z modelu widoku.

Answer 1

Ponieważ dyspozytor jest problematyczny w testach jednostkowych, moim rozwiązaniem byłoby złamanie zależności modelu widoku od dyspozytora. Zakładam, że obecnie masz ciężko kodowane odniesienia, takie jak:

Dispatcher.CurrentDispatcher.BeginInvoke(.. 

dyspozytor jest zewnętrznym zależność i nie powinny być częścią testów jednostkowych - możemy założyć dyspozytor prace.

Używałbym zastrzyku zależności (biedny mans, Jedność, itp.). Utwórz odpowiedni interfejs reprezentujący dyspozytora. Stwórz realną implementację, która otoczy prawdziwego dyspozytora. Utwórz fałszywą implementację, która używa Action.BeginInvoke. W fałszywej rejestracji wszystkie IAsyncResults wróciły do ​​wywołań BeginInvoke.
Następnie należy użyć metody pomocnika, która będzie czekać na wszystkie połączenia, które można wykorzystać w teście, aby czekać na zakończenie.

Lub mieć klasę podstawową modelu widoku, która robi to samo. W normalnych warunkach wywołuje dyspozytora, ale można go skierować, aby wywołać fałszywkę podczas testów.

Answer 2

Znalazłem proste rozwiązanie. Zamiast przetwarzania Asynchronizacji klatek w Dispatcherze dodałem kolejną zsynchronizowaną metodę do klasy DispatcherUtil. Wywołanie tej DoEventsSync() - metoda powraca gdy wszystkie ramki zostały przetworzone, myślę, że to powinno pomóc tutaj:

public static class DispatcherUtil 
    { 
     [SecurityPermission(SecurityAction.Demand, Flags = SecurityPermissionFlag.UnmanagedCode)] 
     public static void DoEvents() 
     { 
      var frame = new DispatcherFrame(); 
      Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background, 
       new DispatcherOperationCallback(ExitFrame), frame); 
      Dispatcher.PushFrame(frame); 
     } 

     public static void DoEventsSync() 
     { 
      var frame = new DispatcherFrame(); 
      Dispatcher.CurrentDispatcher.Invoke(DispatcherPriority.Background, 
       new DispatcherOperationCallback(ExitFrame), frame); 
      Dispatcher.PushFrame(frame); 
     } 

     private static object ExitFrame(object frame) 
     { 
      ((DispatcherFrame)frame).Continue = false; 
      return null; 
     } 
    }