BizTalkでDDD、TDDを使用するにはどうすればよいですか？

Question

仕事でBizTalkを始めたばかりで、DDDやTDDなどについて学んだことをすべて使い続けたいと思っています。パイプラインとオーケストレーション？

Answer 1

TDDおよびDDDの多くの概念をBizTalk開発に確実に適用できます。

ドメインオブジェクトの概念を中心に設計および開発できます（ただし、BizTalkおよび統合開発では、インターフェイスオブジェクトまたはコントラクトファーストデザインの方が、より便利な考え方であることがわかります（インターフェイスで伝達されるメッセージ）。また、「動作する最も単純なものを構築する」と「テストに合格するもののみを構築する」TDDの哲学に従うこともできます。

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

まず、要件を実行して失敗するuntiテストを作成し、次に要件を満たし、テストをパスするメソッドを作成するというテスト駆動開発アプローチに従うことができますか？ C＃のような従来のプログラミング言語ですか？

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

BizUnit と BizUnit拡張機能は、BizTalkアプリケーションの実行を制御し、それらをテストする機能を提供しますが、実際には、より制御されたテスト駆動の統合テストを実行するだけです。

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

グッドデザインプラクティス（TDDなどのアプローチからポインターを取得）は、BizTalkソリューションをより小さく、よりモジュール化されたテスト可能なチャンクに分割することにつながります。また、パイプラインなどを個別にテストする方法があります。

しかし、コード内のTDDおよびDDDの詳細は残念ながら翻訳されません。

有用な関連する議論については、次の質問を参照してください。

BizTalk要求/応答によって消費されるWebサービスのモックポート

Answer 2

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

この種の機能を使用する場合、自分でそう言うことができれば非常に便利です（私は自分のプロジェクトでそれを多用しています）。

ライブラリの概要については、こちらをご覧ください。 、および github の完全なコード。 wiki には、さらに詳細なドキュメントもあります。

Answer 3

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

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

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

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

ESBガイダンスなどのフレームワークを使用すると、作業を進めるための基本プラットフォームを提供できるため、システムを通じて反復的に主要なユースケースを実装できます。

いくつかの考え。お役に立てれば。もっと広範囲にブログを書く価値があると思います。 これは議論するのに適したトピックです。質問がある場合は、pingを実行するか、こちらでいつでも詳細を議論できます。

Rgds ベンジー

Answer 4

BizUnitを使用して、コードとExcelの両方で汎用テストケースを作成および再利用できます（機能シナリオの場合）

http://www.codeplex.com/bizunit

BizTalk Server 2009には、より統合されたテスト容易性が期待されています。

乾杯 ヘミル。

Answer 5

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

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

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