Как утверждать запрос, отправленный в успокоительный веб-сервис из теста BDD (specflow with nunit)

Question

Я пишу тест стиля BDD для нового требования от клиента.

Просто для того, чтобы дать фон в системе. У нас есть служба Windows, которая слушает TCP-порт. Эта служба Windows отвечает за обработку сообщений, отправляемых клиентами на порт, и отвечает на клиентов.

Обработка включает

1) найти правильное сообщение processer на основании запроса
2), то при форматировании запроса о том, что служба третьей стороны может понять
3) отправить форматированный запрос на третью сторону RESTful веб-сервис
4) отформатируйте ответ, полученный от веб-службы, и отправьте его в клиентский сокет.

Для целей BDD мы создали самообслуживаемую восстановительную службу, которая будет отправлять ответы на основе настроенных сообщений для каждого запроса.

До сих пор все наши тесты основаны на том, что мы отправляем в порт, и какой ответ мы получили в порту. При таком подходе мы смогли охватить все функциональные возможности тестов BDD.

Теперь новое требование заключается в том, что клиент отправляет дополнительный элемент в тело сообщения, а сторонняя служба также должна получить дополнительный элемент. Если клиент не отправляет дополнительный элемент в тело сообщения, мы не должны даже отправлять этот элемент в стороннюю службу. Мы сделали это изменение (обновили класс запроса POCO с помощью метода ShouldSerialize), а также проверили результат с использованием файлов журнала.

Но мы изо всех сил стараемся покрыть это из теста BDD. Это связано с тем, что наш тест работает как клиент и отправляет сообщения на порт, поскольку мы контролируем только ответ, полученный от порта, который мы утверждаем только в ответ. У нас нет контроля над вызовом сторонней службы, потому что это происходит внутри кода производственной программы Windows.

Можно ли каким-либо образом перехватить запрос, отправляемый в тестовую службу, чтобы подтвердить запрос, чтобы проверить, отформатирован ли запрос, как ожидалось.

Примечание: Мы используем C#, specflow с Nunit.

Answer 1

Похоже, у вас есть кусок промежуточного слоя, который должен иметь свои собственные тесты:

{Your Application} --> {Middleware} --> {3rd Party Service} 
               | 
{Your Application} <-- {Middleware} <------------+ 

Вы должны быть создание модульных тестов или функциональных тестов для middlware отдельно от большего применения в целях протестируйте эту новую функциональность мультимедиа.

В вашем полном приложении не проверяйте связь между промежуточным программным обеспечением и сторонним сервисом. Это черная дыра, из которой вы никогда не появится.Вы остались с тремя наборами тестов:

1. Validate, что {Your Application} <--> {Middleware} работает
2. Validate, что {Middleware} <--> {Mock 3rd Party Service} работает
3. Развертывание приложений и промежуточное программное обеспечение в среде, где эти услуги проводную должным образом, и сделать некоторые ручное тестирование.

user2389992 прокомментировал:

Я не могу написать тест для первой точки из BDD, потому что у меня есть контроль только написать запрос в порт и утверждать ответ на порт.

Ключевая часть здесь: «У меня есть контроль только для того, чтобы написать запрос в порт и утвердить ответ». Тест BDD не должен углубляться. Услуга - черный ящик. Вам не нужно знать, что он делает, чтобы протестировать ваше основное приложение. Вам просто нужно знать: «Если я отправлю эту услугу, она вернет мне это».

Вам нужен совершенно отдельный набор тестов, обеспечивающий правильное взаимодействие промежуточного программного обеспечения/службы с сторонним сервисом.

Наконец, вам понадобится третий полностью отдельный набор ручных тестов в прикладной среде с вашим приложением, промежуточное программное обеспечение и сторонняя служба, подключенные к сети, чтобы убедиться, что интеграция этих слоев работает правильно.

Answer 2

Я думаю, что ваш единственный вариант - иметь возможность запускать ваш тест с помощью заглушки. Стороннее обслуживание, которое вы затем можете запросить для проверки, вызывается правильно.

Возможно, вы сможете создать тестовую прокси-службу, которая регистрирует вызов где-нибудь для проверки, а затем вызывает фактическую услугу. Вы можете уйти с простым декоратором для своего первоначального обслуживания.

Answer 3

Вы пытаетесь описать свой API своими тестами BDD, чтобы получить документацию определенного типа? Возможно, следующая статья может быть полезна: http://java.dzone.com/articles/documenting-api-using