0

MVC プロジェクトから REST サービスへの呼び出しを抽象化するために使用するサービス マネージャー クラスがあります。マネージャー クラスが行うことは、(RestSharp を使用して) Rest 呼び出しをセットアップし、サービス データを MVC アプリケーションに返すことだけです。

そのため、最初はそのような些細なクラスをテストしないことを考えていましたが、テストによって、より複雑になる可能性のある将来の変更を防ぐことができると判断しました。

しかし、ここに私のジレンマがあります。単独でテストできるようにするには、どこまで抽象化する必要がありますか?

そのため、RestClient が MVC によってマネージャー クラスに注入されています。MVC インジェクターにベース URL を設定させています。これはすべて問題ありませんが、ここに私が持っている質問があります：

  • メソッド呼び出しの場合、メソッドにパラメーター (userId) と IRestRequest を取り込ませる必要がありますか?
    • これに関する私の問題は、インターフェースに両方のパラメーターを含める必要があるため、突然、汎用サービスマネージャーが REST 固有になることです。
  • IRestRequest をメソッドに挿入せず、実装に作成させた場合、これは無視されるため、これは問題ありませんか? テストされるメイン メソッドは RestClient.Execute であり、スタブ化され、実際の RestRequest を気にしません。
    • 実際、これは実装の一部であるため、適切な RestRequest オブジェクトで Execute メソッドが送信されていることをモックして確認できますか?
  • または、IRestRequest を注入するのではなく、代わりに IRequestResolver をコンストラクターに注入する必要がありますか? 次に、メソッド呼び出しで、メソッドを表す文字列を受け取る IRequestResolver を使用できます。これは、RestRequest パラメーターを把握し、メソッドに適切に入力された RestRequest オブジェクトを返すために使用されますか?
  • または、基本的に最初の箇条書きの下にサブ箇条書きを作成し、具体的な実装を使用する必要があります。
  • 私が見逃している他のオプションはありますか？

テストされている実際のソリューションになると、4番目の箇条書きに傾いていますか?

私のジレンマを解決するために、さらに詳細が必要な場合はお知らせください。

4

2 に答える 2

1

これについて友人と話し合った後、具体的な実装を使用することにしました。

その理由は、このオブジェクトは実際には単なるPOCOであり、これを抽象化する必要がないためです（抽象化が提供されている場合でも）。これは私のサービス呼び出し元の具体的な実装であるため、テストされる実際のソリューションは呼び出しです。私はおそらくこれをモックアウトして、restrequestが本来あるべき方法で呼び出されていることを確認します。

しかし、私たちが思いついた簡単な答えは、POCOを抽象化する必要はないということです。

于 2012-02-29T00:35:07.520 に答える
1

私はこのジレンマをよく知っています。ここに数回来ました。

結局のところ、すべてを抽象化できますが、意味のないテストになってしまい、問題のないテスト フレームワークを書いているか、「1 つ真のテスト方法論」。私は実際に、整数を入れるだけでよい抽象的なインターフェースを渡すことについて人々が正直に議論した会話に参加しました。

これを書いている間、私はあなた自身の答えを見てきました。と私は完全に同意します。

仮定を検証し、動作をテストできる限り、十分に行っています。あなたが言うように - 物事が変わったことを確認するだけでよく、あなた自身が自分のコンテキストの境界を知っています - プロバイダーは現実的に変化しますか? いいえ - 抽象化しないでください。

最近、私は雇用主のためにいくつかの大規模な Microsoft Dynamics CRM ソリューションを設計しました。最終的に私のテストでは、CRM API が問題ないと仮定しており、ラッパーの動作をテストしているだけです。

とにかく、それは私が見ている大まかなところです。これがあなたにとって何らかの価値があることを願っています!

于 2012-02-29T00:41:56.033 に答える