Как я могу все еще использовать DDD, TDD в BizTalk?

Question

Я только начал работать в BizTalk на работе и хотел бы продолжать использовать все, что я узнал о DDD, TDD и т. Д. Возможно ли это или мне всегда придется использовать Visio-подобные редакторы при создании таких вещей, как трубопроводы и оркестровки?

Answer 1

Вы, безусловно, можете применить множество концепций TDD и DDD к разработке BizTalk.

Вы можете проектировать и развивать на основе концепции доменных объектов (хотя в BizTalk и разработке интеграции я часто нахожу объекты интерфейса или первый контрактный дизайн более полезным способом мышления - какие сообщения передаются на моих интерфейсах). И вы также можете следовать принципам «Построить простейшую вещь, которая будет работать» и «строить только те вещи, которые делают тесты успешными». TDD.

Однако ваш вопрос звучит так, как будто вы спрашиваете больше о кодах-сторонах этих подходов к проектированию и разработке.

Прав ли я, что вы хотели бы иметь возможность следовать основанному на тестах подходу к разработке: сначала написать тест unti, который выполняет требование и не прошел, а затем написать метод, который удовлетворяет этому требованию и заставляет тест пройти - все в пределах традиционный язык программирования, такой как C #?

На это, к сожалению, ответ - нет. Большинство артефактов BizTalk (конвейеры, карты, оркестровки ...) действительно могут быть построены только с помощью плагинов Visual Studio BizTalk. Существуют способы просмотра базового кода на C #, но никогда не захочется напрямую разрабатывать этот код.

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

Фигуры, которые вы перетаскиваете на поверхность дизайна Orchestration, в основном будут выполнять свою функцию как непрозрачная единица исполнения. И оркестровки, конвейеры, карты и т. Д. - все это в основном предназначено для выполнения (и тестирования) в рамках всего решения BizTalk.

Надлежащие методы проектирования (с использованием указателей из подходов, таких как TDD) приведут к разбивке решений BizTalk на более мелкие, более модульные и тестируемые блоки, а также есть способы тестирования таких вещей, как конвейеры в изоляции.

Но, к сожалению, подробные сведения о TDD и DDD в коде не переводятся.

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

Mocking WebService, используемый портом запроса-ответа Biztalk

Answer 2

Я согласен с комментариями CKarras. Многие называют это причиной своей неприязни к структуре BizUnit. Но взгляните на BizUnit 3.0. Он имеет объектную модель, которая позволяет писать весь шаг теста на C # / VB вместо XML. BizUnitExtensions также обновляется до новой объектной модели.

Преимущества системы, основанной на XML, заключаются в том, что легче генерировать этапы тестирования и нет необходимости перекомпилировать их при обновлении. В моей собственной библиотеке расширений я обнаружил, что XmlPokeStep (вдохновленный NAnt) очень полезен. Моя команда может обновить тестовый шаг xml на лету. Например, допустим, нам пришлось вызвать веб-сервис, который создал запись клиента, а затем проверил базу данных на эту же запись. Теперь, если веб-сервис вернул идентификатор (сгенерированный динамически), мы могли бы обновить шаг теста для следующего шага на лету (конечно, не в том же XML-файле), а затем использовать его для проверки базы данных.

С точки зрения кодирования, значение intellisense теперь должно быть решено в BizUnit 3.0. Отсутствие XSD усложняло ситуацию в прошлом. Я надеюсь выпустить XSD, который поможет в интеллигенции. Были также некоторые фрагменты для старой версии BizUnit, но они не были обновлены, может быть, если будет время, я попробую.

Но, возвращаясь к проблеме TDD, если вы возьмете часть намерения, лежащего в основе TDD - элемента, определяемого спецификацией или поведением, то вы можете применить его в некоторой степени и к разработке Biztalk, поскольку BizTalk в значительной степени основан на разработке по контракту , Таким образом, вы можете сначала указать свои интерфейсы и создать оркестровки заглушек и т. Д. Для их обработки, а затем создать ядро. Вы можете написать тесты BizUnit в то время. Я хотел бы, чтобы были некоторые инструменты, которые могли бы автоматизировать этот процесс, но сейчас их нет.

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

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

Rgds Бенджи

Answer 3

Если вы часто используете конвейеры и пользовательские конвейерные компоненты в BizTalk, вам может пригодиться моя собственная библиотека PipelineTesting. Он позволяет вам использовать NUnit (или любую другую среду тестирования, которую вы предпочитаете) для создания автоматических тестов для полных конвейеров, конкретных компонентов конвейера или даже схем (таких как схемы плоских файлов).

Это довольно полезно, если вы используете такую ​​функциональность, если можно так выразиться (я активно использую ее в своих проектах).

Вы можете найти введение в библиотеку здесь , а полный код на github . В wiki .

также есть более подробная документация.

Answer 4

BizUnit действительно неудобно, потому что все тесты написаны на XML, а не на языке программирования.

В наших проектах мы «портировали» части BizUnit на простую старую тестовую среду C #. Это позволяет нам использовать библиотеку шагов BizUnit непосредственно в коде C # NUnit / MSTest. Это делает тесты более простыми для написания (с использованием VS Intellisense), более гибкими и, что наиболее важно, более удобными для отладки в случае сбоя теста. Основным недостатком этого подхода является то, что мы разветвились из основного источника BizUnit.

Еще один интересный вариант, который я бы рассмотрел для будущих проектов, - BooUnit , который представляет собой оболочку Boo поверх BizUnit. Он имеет преимущества, аналогичные нашему «порту» BizUnit, но также имеет то преимущество, что все еще использует BizUnit вместо того, чтобы разветвляться из него.

Answer 5

Вы можете использовать BizUnit для создания и повторного использования общих тестовых случаев как в коде, так и в Excel (для функциональных сценариев)

http://www.codeplex.com/bizunit

Ожидается, что BizTalk Server 2009 будет иметь более интегрированную тестируемость IDE.

Приветствие Hemil.