Qual è il modo migliore per automatizzare i test di integrazione MSMQ con Visual Studio Test suite / NUnit?

Question

Vorrei creare una serie di test di unità automatizzati per un'applicazione MSMQ che sto scrivendo. A mio avviso, la sfida è come accogliere i gestori di eventi dal metodo di test. Cioè, invio un messaggio dal metodo di prova e devo restituire un risultato a quel metodo di prova che il messaggio è stato ricevuto e gestito. Non ho idea di come raggiungere questo obiettivo e qualsiasi direzione sarebbe molto apprezzata.

Answer 1

Stai cercando un modo per scrivere unit test in cui il sistema in prova pensa di ricevere eventi da una coda, ma non vuoi usare una vera coda durante i test?

Guarda Rhino Mocks . Ti consente di creare una versione simulata della tua interfaccia di coda, e quindi generare eventi da essa durante il test. Alcuni pseudo codici per testare il metodo Requester.DoSomething () potrebbero apparire così:

// 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();

Dai un'occhiata alla Rhino mock wiki per tutti i dettagli.

Answer 2

In genere un test unitario dovrebbe isolare il metodo da testare. Non ho familiarità con MSMQ ma normalmente creeresti un oggetto finto e lo passerai al tuo metodo di produzione. Quindi puoi percepire cosa ha fatto il metodo all'oggetto finto per verificarne il comportamento corretto e inviare la risposta prevista. Il metodo di produzione non conoscerà la differenza. Il test unitario è più per garantire che i tuoi metodi si comportino come previsto isolatamente.

Il suono è come quello che stai cercando è un test di integrazione. È ancora possibile utilizzare i framework di unit test per ottenere questo risultato, ma non li includerei in una build automatizzata. Li sposterei su una macchina di prova dedicata. I test unitari in genere arrestano una build in quanto indicano una classe o un metodo che non si comporta come previsto. Dove indicano i test di integrazione e i metodi o le classi non interagiscono tra loro come previsto.