2009-05-06 8 views
3

Я хотел бы создать серию автоматических модульных тестов для приложения MSMQ, которое я пишу. Как я вижу, задача состоит в том, как разместить обработчики событий из метода тестирования. То есть, я отправляю сообщение из метода тестирования и должен вернуть результат обратно к этому методу тестирования, чтобы сообщение было получено и обработано. Я не имею ни малейшего представления о том, как это сделать, и любое направление было бы весьма признательным.Каков наилучший способ автоматизации тестирования интеграции MSMQ с помощью Visual Studio Test Suite/NUnit?

ответ

1

Вы ищете способ написания модульных тестов, в которых тестируемая система считает, что она принимает события из очереди, но вы не хотите использовать настоящую очередь во время тестов?

Отъезд Rhino Mocks. Он позволяет создавать макетную версию вашего интерфейса очереди, а затем поднимать события из нее во время теста. Некоторые псевдо-код, чтобы проверить метод Requester.DoSomething() может выглядеть следующим образом:

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

Отъезд Rhino mocks wiki для всех деталей.

1

Как правило, единичный тест должен изолировать тестируемый метод. Я не знаком с MSMQ, но вы обычно создаете макет объекта и передаете его вашему методу. Затем вы можете понять, что метод сделал с макетным объектом, чтобы проверить правильность его поведения и отправить ожидаемый ответ. Метод производства не будет знать разницы. Единичное тестирование больше для обеспечения того, чтобы ваши методы вели себя как ожидалось в изоляции.

Звучит как то, что вы ищете, является интеграционным тестом. Вы все еще можете использовать модульные модули тестирования для выполнения этого, но я бы не включил их в автоматическую сборку. Я бы переместил их на специальную тестовую машину (ы). Единичные тесты обычно останавливают сборку, поскольку они указывают класс или метод, который не ведет себя так, как ожидалось. Где, как показывают тесты интеграции, и методы или классы не взаимодействуют друг с другом, как ожидалось.

+0

Спасибо - Я закончил тесты по методам, но я предполагаю, что я ищу, это скорее интеграционный тест. Тем не менее, я хотел бы выполнить эти тесты ala NUnit, где у меня есть набор элементов, которые я ожидаю для удовлетворения моих условий тестирования. –

+0

NUnit должен отлично работать для этого. Однако тестирование интеграции намного сложнее, чем модульное тестирование. Как минимум вам понадобятся экземпляры отправляющего и принимающего классов и некоторый способ захвата состояния каждого из них. Это может включать подклассификацию ваших производственных классов и изменение модификаторов доступа, чтобы выставлять поля, обычно закрытые. Это действительно зависит от дизайна вашего приложения. –

Смежные вопросы