2

仕事で BizTalk を使い始めたばかりで、DDD や TDD などについて学んだことをすべて使い続けたいと思っています。パイプラインやオーケストレーションなどを作成するとき、これは可能ですか、それとも常に Visio のようなエディターを使用する必要がありますか? ?

4

5 に答える 5

2

確かに、TDD と DDD の多くの概念を BizTalk 開発に適用できます。

ドメイン オブジェクトの概念に基づいて設計および開発を行うことができます (ただし、BizTalk および統合開発では、インターフェイス オブジェクトまたはコントラクトの最初の設計がより有用な考え方であることがよくあります。つまり、どのメッセージがインターフェイスで渡されるかということです)。また、「機能する最も単純なものを構築する」および「テストに合格するものだけを構築する」という TDD の哲学に従うこともできます。

ただし、あなたの質問は、これらの設計および開発アプローチのコード中心の側面についてさらに質問しているように聞こえます。

最初に要件を実行して失敗する unti テストを作成し、次に要件を満たし、テストに合格するメソッドを作成するというテスト駆動開発アプローチに従うことができるようにしたいというのは正しいですか? すべて従来のプログラミング内で行われます。 C#のような言語?

それについては、残念ながら答えはノーです。BizTalk アーティファクト (パイプライン、マップ、オーケストレーションなど) の大部分は、Visual Studio BizTalk プラグインを使用してのみ実際に構築できます。基礎となる c# コードを表示する方法はありますが、このコードを直接開発しようとは思わないでしょう。

BizTalk アプリケーションの実行を制御し、それらをテストする機能を提供するBizUnitとBizUnit Extensionsの 2 つのツールがありますが、これは実際には、より制御された、よりテスト駆動型の統合テストを実行するポイントに到達するだけです。

オーケストレーション デザイン サーフェイスにドラッグする形状は、ほとんどの場合、1 つの不透明な実行単位として機能します。そして、オーケストレーション、パイプライン、マップなど... これらはすべて、主に BizTalk ソリューション全体で実行 (およびテスト) することを目的としています。

優れた設計プラクティス (TDD などのアプローチから指針を得る) は、BizTalk ソリューションをより小さく、よりモジュール化されたテスト可能なチャンクに分割することにつながります。また、パイプラインなどを分離してテストする方法はありますか。

しかし、コード内の TDD と DDD の詳細な仕様は、悲しいことに翻訳されていません。

役立つ可能性のある関連する議論については、次の質問を参照してください。

Biztalk 要求応答ポートによって消費される WebService のモック

于 2008-11-13T03:58:55.543 に答える
1

CKarras のコメントに同意します。BizUnit フレームワークが気に入らない理由として、多くの人がそれを挙げています。しかし、BizUnit 3.0 を見てください。XML ではなく C#/VB でテスト ステップ全体を記述できるオブジェクト モデルがあります。BizUnitExtensions も新しいオブジェクト モデルにアップグレードされています。

XML ベースのシステムの利点は、テスト ステップの生成が簡単で、ステップを更新するときに再コンパイルする必要がないことです。私自身の拡張ライブラリでは、XmlPokeStep (NAnt に触発された) が非常に便利であることがわかりました。私のチームは、テスト ステップ xml をオンザフライで更新できました。たとえば、顧客レコードを作成し、同じレコードのデータベースをチェックする Web サービスを呼び出す必要があるとします。Web サービスが (動的に生成された) ID を返した場合、その場で次のステップのテスト ステップを更新し (もちろん、同じ xml ファイルではありません)、それを使用してデータベースをチェックできます。

コーディングの観点から、インテリセンスは BizUnit 3.0 で対処する必要があります。XSD の欠如は、過去に物事を困難にしました。インテリセンスに役立つXSDを入手したいと思っています。古いバージョンの BizUnit のスニペットもいくつかありましたが、それらは更新されていません。時間があれば試してみます。

しかし、TDD の問題に戻ると、TDD の背後にある意図 (仕様または動作駆動型の要素) を取り上げると、BizTalk は契約駆動型の開発に大きく基づいているため、Biztalk の開発にもある程度適用できます。したがって、最初にインターフェイスを指定し、それらを処理するためのスタブ オーケストレーションなどを作成してから、コアを構築できます。その時点で BizUnit テストを作成できます。このプロセスを自動化できるツールがいくつかあればいいのにと思いますが、現在はありません。

ESB ガイダンスなどのフレームワークを使用すると、ベース プラットフォームを利用できるようになり、システムを通じて主要なユース ケースを繰り返し実装できるようになります。

ほんの少しの考え。お役に立てれば。もっと広範囲にブログを書く価値があると思います。これは議論するのに適したトピックです。質問がある場合は、私に連絡してください。いつでもここで議論できます。

Rgds ベンジー

于 2008-12-23T19:49:59.917 に答える
1

BizTalk でパイプラインとカスタム パイプライン コンポーネントを頻繁に使用する場合は、独自の PipelineTesting ライブラリが役立つことがあります。NUnit (または任意の他のテスト フレームワーク) を使用して、完全なパイプライン、特定のパイプライン コンポーネント、またはスキーマ (フラット ファイル スキーマなど) の自動テストを作成できます。

この種の機能を使用すると、非常に便利です (私は自分のプロジェクトで多用しています)。

ライブラリの紹介はこちらで、完全なコードはgithubで見つけることができます。wikiには、より詳細なドキュメントもあります。

于 2008-11-13T12:54:22.007 に答える
0

すべてのテストはプログラミング言語ではなくXMLで記述されているため、BizUnitを使用するのは本当に面倒です。

私たちのプロジェクトでは、BizUnitの一部を単純な古いC＃テストフレームワークに「移植」しました。これにより、BizUnitのステップライブラリをC＃NUnit/MSTestコードで直接使用できます。これにより、（VS Intellisenseを使用して）記述しやすく、柔軟性が高く、最も重要な、テストが失敗した場合のデバッグが容易になるテストが作成されます。このアプローチの主な欠点は、メインのBizUnitソースから分岐していることです。

将来のプロジェクトで検討するもう1つの興味深いオプションは、 BizUnitの上のBooラッパーであるBooUnitです。これには、BizUnitの「ポート」と同様の利点がありますが、フォークする代わりにBizUnitを使用できるという利点もあります。

于 2008-11-13T16:54:02.257 に答える
0

BizUnit を使用して、コードと Excel の両方で一般的なテスト ケースを作成して再利用できます (機能シナリオの場合)。

http://www.codeplex.com/bizunit

BizTalk Server 2009 では、IDE 統合テスト機能がさらに強化される予定です。

乾杯ヘミル。

于 2008-11-13T04:12:35.513 に答える