Quel est le meilleur moyen d'automatiser les tests d'intégration de MSMQ avec la suite de tests Visual Studio Test / NUnit?

Question

Je souhaite créer une série de tests unitaires automatisés pour une application MSMQ que j'écris. À mon avis, le défi consiste à intégrer les gestionnaires d'événements de la méthode de test. C'est-à-dire que j'envoie un message à partir de la méthode de test et que je dois renvoyer un résultat à cette méthode de test indiquant que le message a été reçu et traité. Je ne sais pas comment y parvenir et toute orientation serait grandement appréciée.

Answer 1

Recherchez-vous un moyen d'écrire des tests unitaires dans lesquels le système testé pense recevoir les événements d'une file d'attente, sans pour autant utiliser une vraie file d'attente lors des tests?

Découvrez Rhino Mocks . Il vous permet de créer une version fictive de votre interface de file d'attente, puis de générer des événements à partir de celle-ci lors du test. Un pseudo-code pour tester la méthode Requester.DoSomething () pourrait ressembler à ceci:

// SETUP
MockRepository mocks = new MockRepository();
IQueue mockQueue = mocks.StrictMock<IQueue>();

queue.Received+=null;//create an expectation that someone will subscribe to this event
LastCall.IgnoreArguments();// we don't care who is subscribing
IEventRaiser raiseReceivedEvent = LastCall.GetEventRaiser();//get event raiser for the last event, in this case, Received
Expect.Call(mockQueue.Send).Return(msgId);
mocks.ReplayAll();

// EXEC
Requester req = new Requester(mockQueue);

// We expect this method to send a request to the mock queue object.
req.DoSomething();
// Now we raise an event from the mock queue object.
raiseReceivedEvent.Raise(eventArgs);

// VERIFY
// we would probably also check some state in the Requester object
mocks.VerifyAll();

Consultez le Rhino moque le wiki pour obtenir tous les détails.

Answer 2

Généralement, un test unitaire doit isoler la méthode testée. Je ne connais pas bien MSMQ, mais vous devez normalement créer un objet fictif et le transmettre à votre méthode de production. Ensuite, vous pouvez sentir ce que la méthode a fait à l'objet fictif pour vérifier son comportement et envoyer la réponse attendue. La méthode de production ne saura pas la différence. Les tests unitaires servent davantage à garantir que vos méthodes se comportent comme prévu de manière isolée.

Le son ressemble à ce que vous recherchez est un test d'intégration. Vous pouvez toujours utiliser des frameworks de tests unitaires pour accomplir cela, mais je ne les inclurais pas dans une construction automatisée. Je les déplacerais vers une ou plusieurs machines de test dédiées. Les tests unitaires interrompent généralement une construction car ils indiquent une classe ou une méthode qui ne se comporte pas comme prévu. Où, comme l'indiquent les tests d'intégration, les méthodes ou les classes n'interagissent pas comme prévu.