2017-07-03 1 views
0

J'ai quelques tests qui s'exécutent dans le flux de travail de mon programme WPF. Je fais l'approche MVVM normale qui lie les boutons de la vue aux commandes du modèle de vue, qui gère ensuite l'événement. La façon dont mes tests testent mon flux de travail consiste alors à exécuter directement les commandes sur le modèle de vue. Cela se traduit à peu près à ressembler à quelque chose comme:Comment gérer les exceptions dans les méthodes async void avec NUnit

[Test] 
public void Test() 
{ 
    var vm = new ViewModel(); 
    vm.AcceptCommand.Execute(); 
    Assert.IsTrue(stuff); 
} 

Tout cela fonctionne bien, à l'exception du fait que le code dans la viewmodel qui gère la commande finit par être une méthode vide async car cela devient juste un gestionnaire d'événements. Si une exception est levée ici, nunit n'affiche pas de test défaillant car il ne "voit" pas cette exception dans le thread d'arrière-plan.

Ma question est la suivante: existe-t-il un moyen de faire en sorte que NUnit gère ces exceptions en arrière-plan?

Répondre

0

Il existe une méthode distincte NUnit vérifier exceptions async méthodes:

var exception = Assert.ThrowsAsync<NotImplementedException>(() => vm.AcceptCommand.Execute()); 

ou vice versa:

Assert.DoesNotThrowAsync(() => vm.AcceptCommand.Execute()); 
+0

Cela ne fonctionne pas dans mon cas puisque le gestionnaire d'événements est vide async si l'exception « échappe » le contexte de nunit – ptsoccer

1

S'il est possible refactorisons alors votre méthode en 2 méthodes. Le premier devrait renvoyer la tâche et c'est celui qui est testable. L'autre devrait appeler et attendre la première méthode. Cette indication est tirée de Concurrency dans C# Cookbook par Stephen Cleary. C'est la méthode préférée. Ce livre mentionne également la classe AsyncContext de AsyncEx library qui permet de tester les méthodes async void.

AsyncContext.Run(() => 
{ 
    // put your code here 
}) 

Citation du même livre: Le type de AsyncContext attendra jusqu'à ce que toutes les opérations asynchrones complètes (y compris les méthodes vides) et async se propagent des exceptions qu'ils soulèvent.

Jetez un oeil ici pour discussion similaire: Await a Async Void method call for unit testing

+0

Dans mon cas, l'appel d'une méthode différente au cours du test n'est pas toujours possible car plusieurs de mes tests s'exécutent à un niveau supérieur et ne pourront pas appeler une méthode différente (puisque ce ne sera pas celui qui fait l'appel). Je n'aime pas non plus le fait que ce n'est pas automatique, car je (ou toute autre personne travaillant sur le projet) doit me rappeler de faire cette chose spéciale. L'AsyncContext est intrigant cependant, j'étudierai que la prochaine chance que je reçois. – ptsoccer