Pourquoi ma vérification Moq IEventAggregator échoue-t-elle?

Question

J'utilise Composite WPF (Prism) et j'essaie de tester unitaire que mon Controller s'abonne effectivement à un événement composite.

Mon code d'abonnement se présente comme suit ...

//Init Events. 
this.eventAggregator.GetEvent<PlantTreeNodeSelectedEvent>().Subscribe(
    ShowNodeDetails, ThreadOption.UIThread); 

Mon code de tests unitaires se présente comme suit (je l'utilise Moq comme mon cadre moqueur et l'unité comme mon cadre DI) ...

Mock<PlantTreeNodeSelectedEvent> eventBeingListenedTo = new Mock<PlantTreeNodeSelectedEvent>(); 
eventAggregatorMock.Setup(e => e.GetEvent<PlantTreeNodeSelectedEvent>()).Returns(eventBeingListenedTo.Object); 


//Initialize the controller to be tested. 
IPlantTreeController controllerToTest = container.Resolve<IPlantTreeController>(); 


//Verify. 
eventBeingListenedTo.Verify(
    e => e.Subscribe(It.IsAny<Action<string>>(), ThreadOption.UIThread)); 

Cette méthode est appelée s'abonner (je l'ai vérifié en exécutant avec le débogueur), mais Verify échoue toujours avec « n'a pas été réalisée Invocation sur la maquette: e => e.Subscribe ... »

A ny idée de ce que je fais mal?

Answer 1

Dans votre code, il semble que l'instance eventAggregatorMock n'est jamais utilisée. Je suppose que vous avez besoin de l'enregistrer avec le conteneur afin qu'il soit utilisé par controllerToTest.

Answer 2

1. Vous semblez tester trop dans votre test unitaire. Vous ne devriez pas avoir besoin d'un conteneur, vous devriez simplement créer votre contrôleur fournissant des dépendances fictives, car vous ne devriez tester qu'une chose dans un test unitaire (vous n'avez pas besoin de tester que le framework DI fonctionne normalement ;-)). Il s'assurera également que vous fournissez les mocks correctes, maintenant il n'est pas clair à partir de votre code comme Mark Seemann l'a souligné dans sa réponse.

2. Vous pouvez essayer de configurer un appel de méthode en question au début. Parfois, il semble aider moq à vérifier la classe de manière appropriée. Dans ce cas, vous pouvez également configurer votre comportement de simulation comme étant Strict dans le constructeur, de sorte que le test échoue pour d'autres appels inattendus dans votre maquette.

---

eventBeingListenedTo.Setup(e => e.Subscribe(It.IsAny<Action<string>>(), ThreadOption.UIThread)); 

Answer 3

utiliser un aggrégateur moqueur comme celui-ci (pour Rhino.Mocks) http://adammills.wordpress.com/2010/12/13/auto-mocking-eventaggregator/

Si vous utilisez ThreadOption.UIThread, il appelle Dispatcher.Invoke qui ne fonctionnera pas sans Boucle de message; qui ne fonctionne normalement pas dans les tests unitaires.