8

CRM 2011でプラグインをデバッグしようとすると、非常に困難になる可能性があります。.pdbファイルをサーバー上の正しい場所に配置することには問題があるだけでなく、コーディングを変更するたびに、プラグインをデプロイして再登録するという面倒な作業を経験することになります。トリガーはCRM自体にあるため、その単体テストを作成するのは困難です。

新しいプラグインの単体テストを作成する現在のプロセスはかなり遅く、エラーが発生しますが、次のようになります。

  1. SDKプラグイン登録ツールを使用して新しいプラグインを登録します
  2. プラグインコードにブレークポイントを設定して、デバッガーをw3wp.exeに接続します。
  3. 実行するように登録されているアクションを介してプラグインをトリガーします。
  4. ブレークポイントに到達すると、パイプラインのプリイメージ、ポストイメージ、およびターゲット値をXMLファイルにシリアル化し、これが単体テストへの入力になります。
  5. デバッグを停止し、RhinoMocksを使用してPluginExecutionContextとServiceProviderをモックし、シリアル化されたXMLファイルを入力パラメーターのスタブとしてロードして、新しい単体テストを作成します。
  6. 各単体テストの開始時と終了時に実行されるメソッドを作成し、単体テストで処理するダミーデータをリセット（最初に削除を試みてから追加）し、テストの終了時にダミーデータを削除します。
  7. シリアル化されたファイルを編集してダミーデータを参照し、プラグインが実行されるたびにまったく同じデータに対して機能することを確認できるようにします。
  8. 単体テストでプラグインを宣言してインスタンス化し、モックオブジェクトを渡します
  9. プラグインを実行し、追加のクエリを実行して、プラグインが期待どおりの作業を実行したことを確認します。失敗時にアサートします。

これはやるのが面倒です。画像を正しく取得することから、ダミーデータを作成し、テストを実行するたびにリセットすることまで、改善の余地はたくさんあるようです。

プラグインをCRMから実際にトリガーすることなく、または最初にCRMでプラグインをデバッグし、テストごとに一意のダミーデータを作成するというすべてのフープラを実行せずに、プラグインを単体テストするにはどうすればよいですか？インジェクションを使用して、単体テストごとにCRMのデータを削除、作成、テスト、検証、および削除する必要をなくすにはどうすればよいですか？

2016年の更新

この質問はまだかなりの数のヒットを得ているので、ユニットテスト用の偽のCRMインスタンスを提供する2つの（私が知っている）オープンソースプロジェクトを追加すると思いました。

  • FakeXrmEasy -Jordiによって作成されました（以下の回答を参照）
  • XrmUnitTest-自分で作成
    • 偽のCRMサービスなど（前提条件、エンティティビルダーなど）
    • プラグイン/ワークフローフェイキングの流暢なサポート
    • モックフレームワークへの依存なし
    • Sucky Documentation（私はそれに取り組んでいます）

違いを比較対照するために私が作成したこのビデオをチェックしてください。

4

3 に答える 3

4

単体テストで使用するために、プラグイン実行コンテキストをファイルにシリアル化します。これを行うcodeplexに関する優れたプロジェクトがありますhttp://crm2011plugintest.codeplex.com/

デバッグと単体テストが簡単になり、実際のテストを「記録」できます。

于 2012-07-27T07:33:27.800 に答える
2

プラグインをCRMから実際にトリガーすることなく、または最初にCRMでプラグインをデバッグし、テストごとに一意のダミーデータを作成するというすべてのフープラを実行せずに、プラグインを単体テストするにはどうすればよいですか？

モック付き。RhinoMocksでモックするクラスについては、このリンクを参照してください。あなたはこの点であなたの道を進んでいるように聞こえます。

インジェクションを使用して、単体テストごとにCRMのデータを削除、作成、テスト、検証、および削除する必要をなくすにはどうすればよいですか？

入力パラメータの値の挿入は、操作するエンティティの手動でクランクされたインスタンスをスタブすることで実行できます。

// Add the target entity     
Entity myStubbedEntity = new Entity("account");
// set properties on myStubbedEntity specific for this test...
ParameterCollection inputParameters = new ParameterCollection();     
inputParameters.Add("Target", myStubbedEntity);     
pipelineContext.Stub(x => x.InputParameters).Return(inputParameters);

xmlデータをキャプチャして入力パラメータコレクション全体を再水和するよりも簡単ではありませんか？

編集：データアクセスの場合、通常の推奨事項は、データアクセスをクラスにラップすることです。リポジトリパターンは人気がありますが、ここで必要なものには行き過ぎです。プラグイン実行クラスの場合、作成時にモッククラスを「注入」します。デフォルトのリポジトリを初期化する空白のコンストラクタと、IRepositoryを受け取る2番目のコンストラクタ。

public class MyPluginStep
{
    ITaskRepository taskRepository;
    public MyPluginStep(ITaskRepository repo)
    {
        taskRepository = repo;
    }
    public MyPluginStep()
    {
        taskRepository = new DefaultTaskRepositoryImplementation();
    }
    public MyExecuteMethod(mypluginstepparams){
        Task task = taskRepository.GetTaskByContact(...);
    }

プラグインの手順の複雑さに応じて、これは各クラスに多くのリポジトリを渡すように進化し、負担になる可能性がありますが、これは必要に応じて複雑さを追加できる基本です。

于 2012-07-26T20:57:15.630 に答える
2

本当に良いオプションの1つは、モックと偽物を処理するモックライブラリを使用することです。自分で作成したかったので、このライブラリを作成するまで、偽物やモックを作成するのに多くの時間を無駄にしてしまいました。FakeXrmEasyをお試しください

于 2016-01-21T15:56:46.730 に答える