5

私は、外部サービスのメッセージングが多いプロジェクトに取り組んでいます。少しだけ「双曲線」の方法で説明すると、システムが Flicker API、Facebook API、および Netflix API にメッセージを送信する必要があるアプリケーションになります。

切断されたシナリオ、ログの懸念事項、開発者の使いやすさ、構成などをサポートするために、ジェネリックと式ツリーを多用するアプローチを使用して実験しました。最終結果は次のようになります。

Messenger<NetflixApi>.SendCustom( netflix => netflix.RecommendMovie("my message"));

全体として、最終結果には満足していますが、テストと接続されていないシナリオに関して、どこかで間違いを犯したか、設計原則を見落としているように感じます。

テスト中に、自動、ユニット、または人間ベースのいずれであっても、最初は DI を使用して「ライブ モード」で正しいアクションを実行するオブジェクト ファクトリを実装し、モックを使用して、何もしない無菌メッセンジャーのようなものを提供しました。テストモードの場合はすべて。

モックが純粋な TDD モードで使用されており、一種のダムオブジェクトとして使用されていないことについて、私は見たり読んだりしただけです。私が見たアプローチは、私が使用しているすべての API が依存している HTTP 通信機能をスタブ化またはモックアウトすることを中心に展開していました。

私の主な懸念は、私が接続すると予想されるすべての異なるサービスが、特定の HTTP 実装を置き換える多くの詳細な作業を行う必要があり、スタブアプローチを使用した場合、これらのサービスごとに 3 つのクラスがあることです。 ( IService、ConcreteService、StubService ) であり、新しいメソッドを実装したり何かを変更したりするときにそれらを維持することは、実際の PITA になります。

現在の実装では、モックを使用して「無菌モード」を無料で取得していますが、特定のテスト プリンシパルに準拠するためだけに余分なものを実装する必要はほとんどありません。

問題は、私が何か不足しているのでしょうか? より便利な方法でモックを使用して、設計原則に違反しましたか?

多くのフープを飛び越えることなく、多くの異なる外部サービスから無菌モードを取得する方法について、誰かアドバイスを提供できますか?

この質問は理にかなっていますか？

すべての答えをありがとう。

編集＃1：

元の質問では明確ではありませんでした。null またはモック オブジェクトは、開発/デバッグ/テスト環境でのみ使用されます。本番環境では、これらのメッセージを送信するコードが実際の実装になります。

この問題にはさまざまな解決策があるようで、それぞれを調査する予定なので、全員に投票しました。

この質問はまだ回答されていないと考えてください。できるだけ多くのアドバイスをいただければ幸いです。

4

3 に答える 3

6

Null Object というデザインパターンがあります。null オブジェクトはインターフェイスを実装するオブジェクトであるため、あなたのようなシナリオで使用できます。

Null オブジェクトに関する重要な点は、システムを壊す可能性のある場所で null を返さないことです。

Null オブジェクトの目的は、実稼働環境で使用されるモックのように、何かの空で単純な実装を持つことです。

最も単純な例は、次のようなものです。

class Logger{
 private static ILogger _Logger;

 static Logger(){
  //DI injection here
  _Logger = new NullLogger(); //or
  _Logger = new TraceLogger();
 }
}

interface ILogger{
 void Log(string Message);
}

internal class TraceLogger:ILooger{
 public void Log(string Message){
  //Code here
 }
}

internal class NullLogger{
 public void Log(string Message){
  //Don't don anything, in purporse
 }
}

これがお役に立てば幸いです

于 2008-12-15T05:25:30.623 に答える
4

質問を明確にする必要があると思います。スタブや期待をテストせずにテストダブルを使用することについて話しているのか（必要なインターフェイスを満たすための偽物として使用するのか）、本番シナリオでモックを使用してサービスを埋めることについて話しているのかどうかはわかりません。利用できません（切断されたシナリオ）。

テスト状況で話している場合：モックはテストダブルです。モックやスタブではなく、偽物を使用してテストすることに何の問題もありません。特定のテストでサービスを使用する必要がなく、テスト対象のオブジェクトが依存している特定のインターフェイスを提供するだけの場合は、問題ありません。これは、テストの原則を破ることではありません。

優れたモックライブラリは、モック、スタブ、フェイクの間の境界線を曖昧にしています。

さまざまなタイプのテストダブルに関するMartinFowlerからの情報のいくつかを見てください。モックはスタブではありません、TestDoubles。

私は、moqが、特定の動作を取得するためにフープをジャンプする必要なしに、ダミー、フェイク、スタブ、およびモックオブジェクト間の連続体を許可する方法が本当に好きです。それをチェックしてください。

切断されたシナリオで本番環境でモックを使用することについて話している場合は...心配です。偽物は、あなたが行うすべての呼び出しに対してnullオブジェクトまたはデフォルト値を返します。これにより、これらのサービスを使用するすべてのコードに複雑さが漏れます（nullの戻り値と空の配列のチェックを処理する必要があります...）。依存関係の模擬実装を受け入れてすべてが機能しているように続行するよりも、依存関係自体が利用できないことを処理するようにコーディングする方が、切断/無菌シナリオの方が理にかなっていると思います。

于 2008-12-15T04:10:01.947 に答える
4

プロキシパターンを確認したいと思うかもしれません。実際のサービスから切り離されていても、さまざまなサービスのように機能するものが必要です。したがって、コードは本物ではなくプロキシと通信する方がよいでしょう。その後、プロキシは現在の接続ステータスに応じて必要な処理を実行できます。

于 2008-12-15T05:57:51.090 に答える