Я работаю в корпоративном проекте, и моя команда отвечает за создание внешнего интерфейса приложения, а другая команда разрабатывает веб-сервисы и предоставила WSDL для всех сервисов, которые будут доступны в рамках этого проекта. На этапе разработки наша локальная среда разработки будет указывать на один из блоков разработки команды, ответственной за создание веб-сервисов. Вполне возможно, что их среда разработки будет шаткой в середине итерации. Чтобы снизить этот риск, мы используем пользовательский интерфейс SOAP на нашем локальном компьютере, запускаем фиктивную службу и занимаемся разработкой. Всякий раз, когда нам нужны разные варианты ответа, мы модифицируем XML ответа локальной службы. Этот процесс работает хорошо, но мне было интересно, есть ли способ, чтобы для каждой службы я создал 10 ответов и развернул их как войну с tomcat на одной из машин, и вся моя команда разработчиков указывает на эту войну, которая выставит то же самое service и на основе параметра может отправить один ответ из 10 ответов, связанных в war. я не хочу тратить на это усилия. Есть ли инструмент, который предоставляет такую функциональность из коробки.
Имитация ответа веб-службы | Объедините пару из них в веб-приложение
Ответы (3)
Если бы вы немного разделили свою внутреннюю архитектуру, это облегчило бы вам жизнь. Вместо того, чтобы позволять клиентскому коду полагаться на внешнюю службу SOAP, было бы полезно определить интерфейс для внутреннего использования. Вы можете назвать это IServiceProxy или каким-то другим именем.
Позвольте клиентскому коду общаться с этим интерфейсом и используйте внедрение зависимостей (DI), чтобы внедрить его экземпляр в клиент. Это означает, что для частого использования в разработке вы можете просто заменить этот интерфейс тестовым двойником (например, Mock).
Если вы должны также иметь службу SOAP, чтобы убедиться, что ваш стек SOAP работает должным образом, следите за так называемым тестовым запахом Shared Fixture. Общий «тестовый» сервис на одном сервере будет Shared Fixture, и он, вероятно, доставит вам больше проблем, чем пользы, потому что разработчики будут перешагивать друг через друга, и это будет узким местом.
Лучшей альтернативой является установка службы SOAP на каждом компьютере разработчика или, если это невозможно, выделенной службы для каждого разработчика.
Вы можете узнать больше об общих приборах и многих других тестовых шаблонах и анти-шаблонах в отличном Тестовые шаблоны xUnit.
Я был в той же ситуации, когда команда тестирования хотела протестировать другой сценарий, который требовал время от времени изменять имитируемый сервис. Поскольку большая часть персонала команды тестирования не была технической, я всегда беспокоился об обновлении макета костюма soapUI. Чтобы избежать этого, я создал полностью веб-приложение для имитации службы с использованием WSDL. Поскольку это полностью веб-тестировщики, они смогли изменить имитацию службы из своих веб-браузеров.
Приложение написано поверх фреймворка soapUI. Он предоставляет такие функции, как автоматическое создание фиктивного ответа SOAP-сообщения, проверка и т. Д. Утилита также позволяет имитировать службу с задержкой, что помогает при тестировании производительности.
Теперь я добавил приложение в SourceForge. Пожалуйста, найдите в ссылке ниже
http://sourceforge.net/projects/easymocker/
(Web Service Mocker — это простая в использовании, полностью веб-утилита для имитации веб-сервисов SOAP. Эта утилита оказывается очень полезной в среде разработки SOA во время модульного тестирования, тестирования интеграции компонентов и тестирования нефункциональных требований.)
Я сталкивался с подобной проблемой ранее
Мы создали фиктивное приложение веб-службы хоста, используя WSDL, для которого требуется фиктивная служба.
Сохранены все разные ответы в разных файлах XML на сервере
В коде веб-службы мы просто помещаем переключатель с уникальным идентификатором в запрос веб-службы, а внутри блока переключателя мы отправляем ответ из определенного XML-файла, хранящегося на сервере, соответствующего уникальному идентификатору.
Это было возможно, поскольку ответ был в основном статическим и будет варьироваться в зависимости от одного уникального идентификатора в запросе.
На сборку и развертывание этого у нас ушло чуть больше дня, так как у нас были под рукой ответы.
Надеюсь, это поможет вам в контексте вашего приложения.
