Podstawowy problem polega na tym, że trudno jest polegać na obiekcie MessageQueue. Generalnie, gdy mam taką sytuację, utworzę interfejs, taki jak IQueue, a następnie utworzę implementację IQueue dla MessageQueue.
Następnie można wprowadzić zależność IQueue za pomocą Moq i sprawdzić, czy klasa działa zgodnie z oczekiwaniami.
coś takiego:
public interface IQueue
{
bool Exists(string path);
MessageQueue Create(string path);
}
Realizacja byłoby coś takiego:
public MessageQueueImplementation : IQueue
{
public bool Exists(string path)
{
return MessageQueue.Exists(path);
}
public MessageQueue Create(string path)
{
return MessageQueue.Create(path);
}
}
Następnie do klasy, która zależy od czegoś kolejka komunikatów jak ten:
public class DependentOnQueue
{
private IQueue queue;
//inject dependency
public DependentOnQueue(IQueue queue)
{
this.queue = queue;
}
public MessageQueue CreateQueue(string path)
{
//implement method that you want to test here
}
}
Teraz możesz wstrzyknąć obiekt IQueue, używając moq do tej klasy, która zależy od wiadomości Kolejkuj obiekt i przetestuj jego funkcjonalność.
słowo, wszystkie moje projekty .NET wydają się kończyć tym interfejsem/obwolutami dla wszystkich zapieczętowanych klas Microsoft (FileInfo, HttpContext, etc etc) – ryber
+1. Jest to również akceptowana odpowiedź na ostatnie 10 "Jak kpić z [klasy X]?" pytania. Nie jestem pewien, dlaczego ludzie tego nie zauważają. –
Klasa wrapper wydaje się działać dobrze jako rozwiązanie, z wyjątkiem metody "Create" (która powinna być statyczna), ponieważ sygnatura dla tej metody zwraca 'System.Messaging.MessageQueue', która nie zaimplementuj 'IQueue'. Czy ktoś wymyślił obejście tego problemu? –