Я только начал работать в BizTalk на работе и хотел бы продолжать использовать все, что я узнал о DDD, TDD и т. Д. Возможно ли это, или мне всегда придется использовать редакторы Visio, создавая такие вещи, как конвейеры и оркестровки?Как я могу использовать DDD, TDD в BizTalk?
Вы можете, конечно, применить множество концепций TDD и DDD к разработке BizTalk.
Вы можете проектировать и разрабатывать концепцию объектов домена (хотя в BizTalk и интеграции я часто нахожу объекты интерфейса или первый проект контракта, чтобы быть более полезным способом мышления - какие сообщения передаются на моих интерфейсах). И вы также можете следовать «Построить простейшую возможную вещь, которая будет работать» и «строить только те вещи, которые делают тесты пройденными» философиями TDD.
Однако, ваш вопрос звучит так, как будто вы спрашиваете больше о кодовых ориентирах этих подходов к разработке и разработке.
Я прав, что вы хотели бы иметь возможность следовать методу разработки, основанному на испытаниях, вначале писать тест, который выполняет требование и терпит неудачу, а затем написание метода, который удовлетворяет требованиям и заставляет пройти тест - все в рамках традиционного языка программирования, такого как C#?
Для этого, к сожалению, ответ отрицательный. Большинство артефактов BizTalk (конвейеры, карты, оркестровки ...) могут быть созданы только с использованием плагинов Visual Studio BizTalk. Есть способы просмотра базового кода C#, но никогда не захочется пытаться и напрямую развивать этот код.
Есть два инструмента: BizUnit и BizUnit Extensions, которые дают возможность контролировать выполнение приложений BizTalk и тестировать их, но на самом деле это только позволяет вам выполнять более контролируемые и более тестовые тесты интеграции.
Формы, которые вы перетаскиваете на поверхность дизайна оркестровки, в значительной степени будут делать свою вещь как одну непрозрачную единицу исполнения. И оркестровки, конвейеры, карты и т. Д. ... все эти вещи в основном предназначены для выполнения (и тестирования) в рамках всего решения BizTalk.
Хорошие методы проектирования (с использованием указателей от таких подходов, как TDD) приведут к разрыву решений BizTalk в более мелкие, более модульные и тестируемые блоки, и есть ли способы тестирования таких вещей, как трубопроводы изолированно.
Но подробные особенности TDD и DDD в коде печально не переводятся.
Для некоторых соответствующих обсуждений, которые могут быть полезны посмотреть на этот вопрос:
Mocking WebService consumed by a Biztalk Request-Response port
Вы можете использовать BizUnit создавать и повторно использовать общие тестовые случаи, как в коде и Excel (для функциональных сценариев)
http://www.codeplex.com/bizunit
Ожидается, что в BizTalk Server 2009 будет больше интегрированной проверки IDE.
Cheers Hemil.
Если вы часто используете конвейеры и компоненты конвейера в BizTalk, вы можете найти мою собственную библиотеку PipelineTesting полезной.Он позволяет использовать NUnit (или любую другую структуру тестирования, которую вы предпочитаете) для создания автоматических тестов для полных конвейеров, конкретных компонентов конвейера или даже схем (например, схем плоских файлов).
Это очень полезно, если вы используете такую функциональность, если можно так выразиться (я сильно использую ее в своих проектах).
Вы можете найти введение в библиотеку here, а также полный код на github. Также есть более подробная документация по ее wiki.
BizUnit действительно больно использовать, потому что все тесты написаны в XML вместо языка программирования.
В наших проектах мы «портировали» части BizUnit на обычную старую платформу C#. Это позволяет нам использовать библиотеку шагов BizUnit непосредственно в коде C# NUnit/MSTest. Это делает тесты, которые легче писать (с использованием VS Intellisense), более гибкие и наиболее важные, легче отлаживать в случае отказа теста. Основным недостатком этого подхода является то, что мы разветвлялись из основного источника BizUnit.
Еще один интересный вариант, который я бы рассмотрел для будущих проектов: BooUnit, который является оберткой Boo поверх BizUnit. Он имеет преимущества, аналогичные нашему порту BizUnit, но также имеет преимущество использования BizUnit вместо того, чтобы разворачивать его.
Я согласен с комментариями CKarras. Многие люди процитировали это как причину неприятия рамки BizUnit. Но взгляните на BizUnit 3.0. Он имеет объектную модель, которая позволяет вам написать весь тестовый шаг в C#/VB вместо XML. BizUnitExtensions также обновляется до новой объектной модели.
Преимуществами системы на основе XML является то, что легче создавать этапы тестирования, и при обновлении этапов нет необходимости перекомпилировать. В моей собственной библиотеке расширений я нашел XmlPokeStep (вдохновленный NAnt) очень полезным. Моя команда могла обновить тестовый шаг xml на лету. Например, скажем, нам пришлось вызвать веб-сервис, который создал запись клиента, а затем проверил базу данных для этой же записи. Теперь, если webservice вернул идентификатор (динамически сгенерированный), мы могли бы обновить тестовый шаг для следующего шага «на лету» (не в том же XML-файле, конечно), а затем использовать его для проверки базы данных.
С точки зрения кодирования intellisense следует рассмотреть сейчас в BizUnit 3.0. Отсутствие XSD действительно осложняло ситуацию в прошлом. Я надеюсь получить XSD, который поможет в intellisense. Были также некоторые фрагменты для старой версии BizUnit, но те, которые были обновлены, возможно, если я дам вам время.
Но, возвращаясь к проблеме TDD, если вы возьмете некоторые из намерений TDD - элемента спецификации или поведения, то вы можете применить его в некоторой степени к развитию Biztalk, а также потому, что BizTalk базируется в основном на контрактном развитие. Таким образом, вы можете сначала указать свои интерфейсы и создать контурные оркестровки и т. Д., Чтобы обрабатывать их, а затем строить ядро. Вы могли бы написать тесты BizUnit в то время. Хотелось бы, чтобы были некоторые инструменты, которые могли бы автоматизировать этот процесс, но сейчас это не так.
Использование фреймворков, таких как руководство ESB, также может помочь вам создать базовую платформу для работы, чтобы вы могли реализовать основные варианты использования через вашу систему итеративно.
Всего несколько соображений. Надеюсь это поможет. Я думаю, что его стоит вести блог о более обширном использовании. Это хорошая тема для обсуждения. Пишите мне, если у вас есть какие-либо вопросы, или мы всегда можем обсудить здесь более подробно.
Rgds Бенджи
Большое спасибо за ваш ответ. Я рад, что есть такие вещи, как BizUnit и расширения BizUnit. Я сделаю это. – 2008-11-13 13:44:42