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

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

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

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

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

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

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

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

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

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

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


person VinothNair    schedule 17.03.2015    source источник
comment
Теперь эта проблема решена путем добавления некоторых методов testhelper в фиктивный сервис restfull. И преобразование ServiceBehavior InstanceContextMode фиктивного сервиса restfull в InstanceContextMode.Single. Всякий раз, когда фиктивный сервис получает запрос, он сохраняет запрос в частной переменной, и в одном из методов testhelper мы возвращаем запрос. Из теста после отправки байтов в TCP мы подключаемся к службе с помощью RestClient, а затем вызываем вспомогательный метод, чтобы проверить, какой запрос служба получила, и утвердили его на основе наших ожиданий.   -  person VinothNair    schedule 29.05.2015


Ответы (3)


Похоже, у вас есть промежуточное ПО, которому нужны собственные тесты:

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

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

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

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

Пользователь 2389992 прокомментировал:

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

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

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

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

person Greg Burghardt    schedule 17.03.2015
comment
Привет, Грег, спасибо. Это почти близко к тому, что я делаю сейчас. У меня есть модульный тест, который охватывает эту функциональность, но не в тесте BDD. Не могли бы вы уточнить ваш пункт 1. Я не могу написать тест для первого пункта из BDD, потому что у меня есть контроль только для записи запроса на порт и подтверждения ответа на порту. С этим ограничением я не могу сказать по тесту BDD, что мое приложение (в данном случае это тест) и промежуточное ПО нормально работают для этого конкретного требования. - person VinothNair; 18.03.2015
comment
С технической точки зрения фреймворки модульного тестирования и bdd очень похожи. Вы можете вызывать классы из тестируемой системы в обоих типах тестовых методов. В результате вы должны иметь возможность использовать инфраструктуру из ваших модульных тестов в ваших тестах bdd для достижения цели проверки формата запроса. - person user3632158; 18.03.2015

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

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

person Sam Holder    schedule 17.03.2015
comment
Привет, Сэм. Спасибо за ваше предложение. В настоящее время я пишу запрос в файл журнала в макете веб-службы. Но не найти более чистого решения для получения информации в тесте. - person VinothNair; 17.03.2015

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

person James    schedule 18.03.2015