Насмешка WebService используется портом Biztalk Request-Response
WSO2 Business Rules server больше не выпускается. Если вы хотите использовать drools с WSO2 EI, EI имеет посредник правила, который можно использовать в конфигурации посредника. Медиатор правил использует слюни внизу. Тем не менее, посредник правила не раскрывает всю функциональность, доступную от drools.
7 ответов
Это переходит к основе одного из моих основных раздражений как разработчик BizTalk - BizTalk не предоставляет его сам поблочному тестированию. От факта 99% Ваших интерфейсов в приложения BizTalk являются базирующимся сообщением и имеют огромное количество возможных исходных данных до непрозрачной природы оркестровок, BizTalk не предлагает реального способа протестировать единицы функциональности как... хорошо... единицы.
Для BizTalk интеграционные тесты являются печально часто единственной возможностью.
Это приводит к, ни из-за какого отказа со стороны Kevin Smith, при этом BizUnit является (IMO) неправильным употреблением. Лучшим именем, возможно, был бы BizIntegrationIt. BizUnit предлагает диапазон инструментов, которые помогают в интеграционном тестировании, большинстве его тестов, как проверка, если файл был записан в данный каталог, или отправка HTTPRequest к местоположению HTTPReceive BizTalk все строго говоря, тестируя интеграцию.
Теперь, когда я вывел ту напыщенную речь, что Вы просите, что-то, о чем я думал в течение долгого времени, способность создать автоматизированные модульные тесты, которые вселяют некоторую реальную веру, что мое создание небольшого изменения карты внезапно не повредит что-то еще в нисходящем направлении, а также способ удалить зависимость от внешних сервисов.
Я никогда не думал ни о каком хорошем способе сделать, это, но ниже является решением, которое должно работать, я сделал изменения каждой части этого в изоляции, но никогда не пытался, но их всех вместе в этой определенной форме.
Так, учитывая требование дразнить вызов к некоторому внешнему сервису (который еще даже не может существовать), не будучи должен на самом деле выполнить любой внешний вызов и желая иметь способность установить ожидания того служебного вызова и указать природу ответа, единственный метод, о котором я могу думать, должен разработать пользовательский адаптер.
Ложный веб-сервис с помощью пользовательского адаптера
При создании пользовательского адаптера ответа запроса, можно включить его Ваш отправлять порт вместо адаптера SOAP. Можно затем указать свойства для адаптера, которые позволяют ему вести себя как насмешка для веб-сервиса. Адаптер был бы подобен в понятии петлевому адаптеру, но позволит внутреннюю логику насмешки.
Вещи, которые Вы могли бы хотеть включать как свойства адаптера:
- Ожидаемый документ (возможно, дисковое местоположение, которое указывает пример того, что Вы ожидаете, что Ваш BizTalk applicaiton отправит в веб-сервис).
- Документ ответа - документ, который адаптер передаст обратно обменивающемуся сообщениями механизму.
- Определенные ожидания теста, такие как справочные значения в элементах документа.
Вы могли также иметь запись пользовательского адаптера к диску и установить шаг BizUnit для проверки файла, который был выписан.
Здание пользовательского адаптера нетривиально, но возможно, можно получить хорошее начало от Мастера Адаптера BizTalk и существует статья о развертывании пользовательских адаптеров здесь.
Существует ошибка в коде, сгенерированном мастером, необходимо будет измениться new Guid(""), кому: new Guid().
Существуют также некоторые примеры создания пользовательских адаптеров в SDK BizTalk.
Другая опция состоит в том, чтобы использовать плоскость http страница, и HTTP требуют ответа, как обсуждено здесь, вся Ваша логика входит в http страницу. Это, вероятно, более просто, если Вы - счастливое наличие вызова http и установка порт IIS для прислушиваний к тесту.
Инициализация модульных тестов
Можно импортировать обязательные файлы в приложение BizTalk с помощью .bat файла.
При создании нового обязательного файла для каждого теста, Вы работаете, а также за своим стандартом applicaiton настроенный, можно затем выполнить соответствующий пакетный файл для применения правильной привязки.
Каждый обязательный файл изменил бы Ваш веб-сервис sendport, чтобы использовать ложный пользовательский адаптер и установить определенные свойства для того теста.
Вы могли затем даже заставить пользовательский BizUnit ступить, который (возможно), генерировал параметры привязки на основе настроек на этапе проверки и затем выполнил команды оболочки для обновления привязки.
Тестирование содержимого сообщения
Заключительной вещью, что Вы могли бы хотеть рассмотреть, действительно связать все это, является некоторый способ протестировать содержание сообщений. Вы могли сделать это в своем ложном адаптере, но это станет утомительным очень быстро для больших сообщений, или для большого спектра возможных входных сигналов.
Одна опция состоит в том, чтобы сделать пользовательский конвейер, который называет Schematron для проверки файлов, которые это получает. Schematron является языком схемы, который позволяет намного более богатый уровень контроля файла, что xsd, таким образом, можно проверить вещи как, "Если элемент x содержит это содержание, я ожидаю, что элемент y будет присутствовать".
При создании пользовательского конвейера, который взял schematron схему в качестве параметра, Вы могли затем загрузить файл тестирования для определенного модульного теста, проверив это для этого теста при вызове веб-сервиса, Вы получаете файл, который на самом деле соответствует тому, что Вы хотите (и не просто соответствует xsd),
Как соавтор BizUnitExtensions (www.codeplex.com/bizunitextensions) я соглашаюсь, что имя "единица" в BizUnit может сбивать с толку, но для Biztalk, 'интеграционный тест' является модульным тестом. Некоторые люди Biztalk успешно использовали насмешки для тестирования конвейерных компонентов и других тестовых обвязок (+ BizUnit/Extensions) для тестирования схем и карт.
Оркестровки, к сожалению, непрозрачны. Но существует, серьезные основания для этого.
(a) Из-за огромной системы подписки в окне сообщения - что оркестровки используют, будучи активированным и т.д., не возможно разжечь некоторый "виртуальный" процесс для хостинга оркестровки (который может быть сделан для конвейеров. Tomas Restrepo сделал что-то вдоль этих строк).
(b) Кроме того, как этот виртуальный процесс обработал бы персистентность и дегидратацию?. Я держал бы пари, что у людей, использующих WF, будет та же проблема в попытке протестировать рабочий процесс полностью.
(c) мы не работаем с C# непосредственно, таким образом, нет никакого способа, которым мы можем "ввести" ложный интерфейс в код оркестровки.
(d) Оркестровка не является действительно "единицей". это - составной элемент. Единицы являются сообщениями, идущими в и от окна сообщения и внешних компонентов, названных через формы выражения. Таким образом, даже если Вы могли бы ввести ложный интерфейс веб-сервиса, Вы не можете ввести ложные окна сообщения и наборы корреляции и другие вещи.
Одна вещь, которая может быть сделана для оркестровок (и я полагал, что дополнение к библиотеке BizUnitExtensions делает это), состоит в том, чтобы связаться в с инструментом OrchestrationProfiler, поскольку тот инструмент дает довольно подробный отчет обо всех формах, и так или иначе проверьте, что отдельные шаги выполнялись (и возможно время, которое потребовалось для выполнения). Это могло пойти довольно далеко в создании оркестровки немного больше белого поля. Также полагая, что отладчик оркестровки показывает много значений переменных, конечно, должно быть возможно заставить ту информацию через API показывать то, чем значения переменных были в данной точке для приведенного примера.
Назад к вопросу Richard, хотя, у моей предыдущей команды разработчиков было решение. В основном то, что мы сделали, должно было записать универсальный настраиваемый HttpHandler, который проанализировал входящие запросы на обслуживание и возвратил предварительно установленные ответы. Переданный обратно ответ настраивался на основе условий, таких как XPath. В СБОРКЕ и DEV обязательные файлы, конечная точка веб-сервиса была насмешкой. Это работало блестяще в изоляции СБОРКИ и сред DEV от фактических сторонних веб-сервисов. Это также помогло в "контракте сначала" подходу, где мы создали насмешку, и orch разработчик использовал его, в то время как автор веб-сервиса шел вперед и создал практическую эксплуатацию.
[Update:17-FEB-09: этот инструмент находится теперь на codeplex: http://www.codeplex.com/mockingbird. Если этот подход звучит как интересная проверка это, и сообщите мне то, что Вы думаете об инструменте]
Теперь, прежде чем кто-то бросает старое "ЧТО ОТНОСИТЕЛЬНО ПЛАТФОРМ ФИКТИВНОГО ОБЪЕКТА", каштановых в, позвольте мне сказать, что утилита выше использовалась и для Biztalk 'потребители', а также не потребители Biztalk, НО я также работал с NMock2 и нашел что быть отличным способом дразнить интерфейсы и установить ожидания при записи потребителям CLR. (Я собираюсь быть изучением MoQ и TypeMock и т.д. скоро). Однако это работа привычки с оркестровками по причинам, описанным выше.
Надеюсь, это поможет.
С уважением,
Benjy
Отказ от ответственности: Я работаю в Typemock.
Я не уверен точно, что необходимо сделать, но я думаю, что следующая ссылка является хорошим началом:
Это - способ сделать это:
Назад к вопросу Richard, хотя, у моей предыдущей команды разработчиков было решение. В основном то, что мы сделали, должно было записать универсальный настраиваемый HttpHandler, который проанализировал входящие запросы на обслуживание и возвратил предварительно установленные ответы. Переданный обратно ответ настраивался на основе условий, таких как XPath
Это - очень интересный вопрос, на который я все еще не видел хороший универсальный ответ. Некоторые люди предлагают использовать SoapUI, но у меня не было времени для фактического тестирования этого все же. Эта страница могла бы быть интересной на этом.
Иначе мог бы быть, чтобы так или иначе перенести WebDev.WebHost.dll и использование это... Phil Hakkck обсуждает это в этом сообщении.
Это также быть обсужденным прежде на, ТАКИМ ОБРАЗОМ, здесь.
Сообщите нам, находите ли Вы другое решение этого!
Я не должен был выполнять в этом некоторое время, но когда я протестировал бы свои Приложения Biztalk, я всегда использовал или мыло ui или студию веб-сервиса. Я смог протестировать различные входные значения без усилия.
Не делать.
Не тестируйте против произвольных интерфейсов и не создавайте насмешки для них.
Большинство людей, кажется, видит, что разработчик (единица) тестирует, как предназначено на тестирование нетривиальных, отдельных единиц функциональности, таких как единый класс. С другой стороны, также важно выполнить клиента (принятие/интеграция) тестирование главных подсистем или всей системы.
Для веб-сервиса нетривиальная единица функциональности скрыта в классах, которые на самом деле выполняют значимый сервис позади коммуникационного проводного соединения. Те классы должны сделать, чтобы отдельный разработчик протестировал классы, которые проверяют их функциональность, но полностью без любого веб-сервисно-ориентированного коммуникационного проводного соединения. Естественно, но возможно не, очевидно, который означает, что Ваша реализация функциональности должна быть отдельной от Вашей реализации проводного соединения. Так, Ваш разработчик (единица) тесты никогда не должен видеть ни одно то специальное коммуникационное проводное соединение; это - часть интеграции, и она может быть просмотрена (соответственно) как проблема "презентации", а не "бизнес-логика".
Клиент (принятие/интеграция) тесты должен обратиться к намного большему масштабу функциональности, но все еще не сфокусированный на проблемах "презентации". Это - то, где использование шаблона Фасада является общим - представление подсистемы с объединенным, крупномодульным, тестируемым интерфейсом. Снова, коммуникационная интеграция веб-сервиса не важна и реализована отдельно.
Однако очень полезно реализовать отдельный набор тестов, которые на самом деле включают интеграцию веб-сервиса. Но я настоятельно рекомендую против тестирования только одной стороны той интеграции: протестируйте его от начала до конца. Это означает создавать тесты, которые являются клиентами веб-сервиса точно так же, как реальный производственный код; они должны использовать веб-сервисы точно способ, которым реальным приложением (приложениями) делают (es), что означает, что те тесты затем служат примерами любому, кто должен реализовать такие приложения (как Ваши клиенты, если Вы продаете библиотеку).
Так, почему переходят ко всей той проблеме?
Ваши тесты разработчика проверяют, что Ваша функциональность работает в-маленьком, независимо от того, как к ней получают доступ (независимый от уровня представления, так как это - вся внутренняя часть уровень бизнес-логики).
Ваши клиентские тесты проверяют, что Ваша функциональность работает в-большом, снова независимо от того, как к ней получают доступ на интерфейсной границе Вашего уровня бизнес-логики.
Ваши интеграционные тесты проверяют, что Ваш уровень представления работает с Вашим уровнем бизнес-логики, который теперь managable, так как можно теперь проигнорировать базовую функциональность (потому что Вы отдельно протестировали его выше). Другими словами, эти тесты фокусируются на тонком слое симпатичной поверхности (GUI?) и интерфейс связи (веб-сервисы?).
Когда Вы добавляете другой метод доступа к Вашей функциональности, только необходимо добавить интеграционные тесты на ту новую форму доступа (уровень представления). Ваши тесты разработчика и клиента гарантируют, что Ваша базовая функциональность неизменна и не повреждается.
Вам не нужны никакие специальные инструменты, такие как инструмент тестирования специально для веб-сервисов. Вы используете инструменты/компоненты/библиотеки/методы, которые Вы использовали бы в производственном коде, точно как Вы будете использовать их в таком производственном коде. Это делает Ваши тесты более значимыми, так как Вы не тестируете чужие инструменты. Это сохраняет Вас много времени и денег, так как Вы не покупаете, развертывание, разработка для, и поддержание для специального инструмента. Однако, если Вы тестируете через GUI (не делайте этого!), Вам, возможно, понадобился бы один специальный инструмент для той части (например, HttpUnit?).
Так, давайте станем конкретными. Предположите, что мы хотим обеспечить некоторую функциональность для отслеживания ежедневное меню кафетерия (потому что мы работаем в мегакорпорации с ее собственным кафе в здании, как мое). Скажем, то, что мы нацелены на C#.
Мы создаем некоторые классы C# для меню, пунктов меню и других мелкомодульных частей функциональности и ее связанных данных. Мы устанавливаем автоматизированную сборку (Вы делаете это, правильно?) использующий nAnt, который выполняет тесты разработчика с помощью nUnit, и мы подтверждаем, что можем создать ежедневное меню и посмотреть на него через все эти маленькие кусочки.
У нас есть некоторая идея того, куда мы идем, таким образом, мы применяем шаблон Фасада путем создания единого класса, который выставляет горстку методов при сокрытии большинства мелкомодульных частей. Мы добавляем отдельный набор клиентских тестов, которые работают только через тот новый фасад, как клиент был бы.
Теперь мы решаем, что хотим предоставить веб-страницу нашим рабочим мегакорпорации знаний для проверки сегодняшнего меню кафетерия. Мы пишем страницу ASP.NET, имеем ее, вызывают наш класс фасада (который становится нашей моделью, если мы делаем MVC), и разверните ее. Так как мы уже полностью протестировали класс фасада через наши клиентские тесты, и так как наша единственная веб-страница так проста, мы предшествуем, запись автоматизировала тесты против веб-страницы - ручной тест с помощью нескольких коллег - рабочих знаний добьется цели.
Позже, мы начинаем добавлять некоторую главную новую функциональность, как способность предварительно заказать наш ланч в течение дня. Мы расширяем наши мелкомодульные классы и соответствующие тесты разработчика, зная, что наши существующие ранее тесты охраняют нас против повреждения существующей функциональности. Аналогично, мы расширяем наш класс фасада, возможно, даже отделяя новый класс (например, MenuFacade и OrderFacade), когда интерфейс растет с подобными дополнениями к нашим клиентским тестам.
Теперь, возможно, изменения в веб-сайте (две страницы веб-сайт, правильно?) делают ручное тестирование неудовлетворительным. Так, мы вводим простой инструмент, сопоставимый с HttpUnit, который позволяет nUnit тестировать веб-страницы. Мы реализуем батарею тестов интеграции/презентации, но против ложной версии наших классов фасада, потому что точка здесь просто, что веб-страницы работают - мы уже знаем, что классы фасада работают. Тестовые данные нажатия и получения по запросу через ложные фасады, только для тестирования этого данные успешно добрались до другой стороны. Ничто больше.
Конечно, наш главный успех предлагает генеральному директору запрашивать (требуют), чтобы мы выставили веб-приложение BlackBerrys мегакорпорации. Таким образом, мы реализуем некоторые новые страницы и новую батарею интеграционных тестов. Мы не должны касаться тестов разработчика или клиента, потому что мы не добавили новой базовой функциональности.
Наконец, запросы технического директора (требования), чтобы мы расширили наше приложение кафетерия до всех автоматизированных рабочих мегакорпорации - Вы действительно замечали их за последние несколько дней? Так, теперь мы добавляем слой веб-сервисов, который связывается через наш фасад. Снова, никакие изменения в нашей базовой функциональности, наших тестах разработчика или наших клиентских тестах. Мы применяем шаблон Адаптера/Обертки путем создания классов, которые выставляют фасад с эквивалентным веб-сервисом API, и мы создаем клиентские классы для потребления того API. Мы добавляем новую батарею интеграционных тестов, но они используют плоскость nUnit для создания клиентских классов API, которые передают по проводному соединению веб-сервиса сервисной стороне классы API, которые вызывают ложные классы фасада, которые подтверждают, что наше проводное соединение работает.
Обратите внимание, что в течение этого целого процесса, нам не было нужно ничто значительное вне нашей производственной платформы и кода, нашей выбранной платформы разработки, нескольких компонентов с открытым исходным кодом для автоматизированного здания и тестирования и нескольких четко определенных батарей тестов. Также обратите внимание, что мы не протестировали ничего, что мы не используем в производстве, и мы ничего не протестировали дважды.
Мы закончили с твердым ядром функциональности (уровень бизнес-логики), который оказался сформировавшийся (гипотетически). У нас есть три отдельных реализации уровня представления: веб-сайт предназначен на рабочие столы, веб-сайт, предназначенный к BlackBerrys и веб-сервису API.
Теперь, простите мне за длинный ответ - я утомляюсь несоответствующими ответами, и я не хотел обеспечивать тот. И обратите внимание на то, что я на самом деле сделал это (хотя не для меню кафетерия).