Asynchrone Commands testen leicht gemacht

Was war das immer für ein Krampf die Execute Methode eines Commands zu testen, das asynchonen Code ausführt. Das hat aber schon seit geraumer Zeit ein Ende. NUnit unterstützt seit der Version 2.6.2 das async await, das mit C# 5.0 der Entwicklerwelt zur Verfügung gestellt wurde.

Für alle Commands, die längere Aktionen ausführen sollen, nutze ich die folgende Klasse:

 public class AsyncCommand<TExecuteArg, TCanExecuteArg> : ICommand  
 {  
      public event EventHandler CanExecuteChanged  
      {  
           add  
           {  
                if (_canExecuteMethod == null)  
                     return;  
                CommandManager.RequerySuggested += value;  
           }  
           remove  
           {  
                if (_canExecuteMethod == null)  
                     return;  
                CommandManager.RequerySuggested -= value;  
           }  
      }  
      public AsyncCommand(Func<TExecuteArg, Task> executeMethod, Func<TCanExecuteArg, bool> canExecuteMethod = null)  
      {  
           if (executeMethod == null)  
                throw new ArgumentNullException("executeMethod");  
           _executeMethod = executeMethod;  
           _canExecuteMethod = canExecuteMethod;  
      }  
      public Task Execute(TExecuteArg arg)  
      {  
           return _executeMethod(arg);  
      }  
      public bool CanExecute(TCanExecuteArg arg)  
      {  
           return _canExecuteMethod == null || _canExecuteMethod(arg);  
      }  
      bool ICommand.CanExecute(object parameter)  
      {  
           return CanExecute((TCanExecuteArg) parameter);  
      }  
      async void ICommand.Execute(object parameter)  
      {  
           await Execute((TExecuteArg) parameter);  
      }  
      private readonly Func<TExecuteArg, Task> _executeMethod;  
      private readonly Func<TCanExecuteArg, bool> _canExecuteMethod;  
 }

Wie man sehen kann, ist die Execute Methode mit dem async Keyword versehen. Alles was in der Execute Action ausgeführt wird, kann also asynchron sein.

Die Benutzung ist einfach, so wie man es vom async/await bzw. von den synchronen Commands her kennt. Hier ein Beispiel in dem im MainViewModel drei Sekunden nach dem Ausführen des Commands eine Nachricht gesetzt werden soll.

 public class MainViewModel : ViewModelBase  
 {  
      public string Message  
      {  
           get { return _message; }  
           set  
           {  
                _message = value;  
                NotifyPropertyChanged("Message");  
           }  
      }  
      public AsyncCommand<object, object> LongRunningCommand { get; private set; }  
      public MainViewModel()  
      {  
           LongRunningCommand = new AsyncCommand<object, object>(OnLongRunningExecute);  
      }  
      private async Task OnLongRunningExecute(object args)  
      {  
           await Task.Run(() => Thread.Sleep(TimeSpan.FromSeconds(3)));  
           Message = "Test message";  
      }  
      private string _message;  
 }

Die OnLongRunningExecute Methode ist hier auch mit dem async Keyword versehen und in der Methode werden dann die drei Sekunden gewartet bevor die Nachricht gesetzt wird.
Diese Implementierung hat den großen Vorteil, das die Anwendung nicht einfriert nachdem der Button geklickt wurde.

Und nun zum eigentlichen Thema: Testen!
Wie schon geschrieben, unterstützt NUnit seit der Version 2.6.2 das Ausführen von asynchronen Tests. Dementsprechend einfach ist es das Command zu testen:

 [TestFixture]  
 public class LongRunningCommand  
 {  
      [Test]  
      public async void Usage()  
      {  
           var viewModel = new MainViewModel();  
           await viewModel.LongRunningCommand.Execute(null);  
           viewModel.Message.Should().Be("Test message");  
      }  
 }

Benutzt man eine ältere Version von NUnit, läuft der Test in weniger als einer Sekunde durch und wird beim Assert schief laufen.

Hier der Sourcecode mit Visual Studio 2012 Solution.

Window Einstellungen in UserSettings komfortabel speichern

Es ist wahrscheinlich schon seit Windows 95 Standard, dass sich eine Anwendung wieder an der Stelle öffnet, an der sie das letzte mal beendet wurde.

WPF spielt hier gut mit den UserSettings zusammen und es können ohne großen Aufwand alle nötigen Daten gesichert und für den nächsten Anwendungsstart wieder geladen werden.

Bei der Settings.settings Datei muss drauf geachtet werden, dass der Zugriff auf public gesetzt wird. Ansonsten müssen einfach alle Eigenschaften eingetragen werden, die gesichert werden sollen.

Im XAML benötigen man noch einen Zugriff auf die Settings. Diesen Zugriff stelle ich in der App.xaml zur Verfügung.

 <Application x:Class="Sample.App"  
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"  
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
        xmlns:properties="clr-namespace:Sample.Properties">  
   <Application.Resources>  
     <ResourceDictionary>  
       <properties:Settings x:Key="Settings" />  
     </ResourceDictionary>  
   </Application.Resources>  
 </Application>

Danach können diese Eigenschaften an dem Hauptfenster der WPF Anwendung gebunden werden. In meinem Beispiel in der MainView.xaml.

 <Window x:Class="Sample.MainView"  
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"  
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
     Width="{Binding Source={StaticResource Settings}, Path=Default.MainViewWidth, Mode=TwoWay}"  
     Height="{Binding Source={StaticResource Settings}, Path=Default.MainViewHeight, Mode=TwoWay}"  
     Top="{Binding Source={StaticResource Settings}, Path=Default.MainViewTop, Mode=TwoWay}"  
     Left="{Binding Source={StaticResource Settings}, Path=Default.MainViewLeft, Mode=TwoWay}"  
     WindowState="{Binding Source={StaticResource Settings}, Path=Default.MainViewWindowState, Mode=TwoWay}"  
     Title="Sample">  
   <Grid />  
 </Window>

Es muss beachtet werden, dass der Mode beim Binding auf TwoWay gesetzt wird, weil die Werte sonst nur gelesen, aber nicht wieder zurück in die Settings geschrieben werden.

Zum Schluss müssen die Einstellungen noch gesichert werden. Das mache ich generell beim Beenden der Anwendung. Ich mache dies allerdings nur, wenn die Anwendung ordnungsgemäß beendet wird, um ggf. einen inkonsistenten Zustand der Daten zu verhindern. Diesen Zustand wird es bei den hier gezeigten Eigenschaften zwar nie geben, allerdings können ja noch beliebig viele andere Eigenschaften in den Settings gesichert werden, bei denen die Konsistenz sichergestellt werden muss.
In der App.xaml.cs habe ich demnach die OnExit Methode überschrieben und rufe dort ggf. die Save Methode der Settings Klasse auf.

 public partial class App  
 {  
      protected override void OnExit(ExitEventArgs e)  
      {  
           base.OnExit(e);  
           if (e.ApplicationExitCode == 0)  
                Settings.Default.Save();  
      }  
 }

Nun sollte sich bei jedem Start der Anwendung das Fenster genau dort wieder öffnen, an der es zuletzt auch geschlossen wurde.