1

Web サービス呼び出しを行う AS3 クラスを効果的にテストする際に、概念的な問題に直面しています。次のコード例を見てください。

class ServiceWrapper extends EventDispatcher
  public function doStuff():void {
    var loader:URLLoader = new URLLoader;
    var request:URLRequest = new URLRequest();
    request.url = 'http://myapiendpoint.com/foo';
    var self:ServiceWrapper = this;
    loader.addEventListener(Event.COMPLETE, function(event:Event):void {
      if(loader.data == 'success') {
        this.dispatchEvent('stuffDone');
      } else {
        this.dispatchEvent('stuffNotDone');
      }
    });
    loader.load(request);
  }
end

サービスが「成功」を返した場合、インスタンスがstuffDoneイベントタイプをディスパッチし、そうでない場合はstuffNotDone.

アプリケーション コードで「テスト インターフェイス」を公開せずに、Web サービスの応答をモックする方法はないように思われます。たとえば、次の例が思い浮かびます。

  • パブリックloader属性にするか、パブリックから返され、テストでモックに置き換えます。
  • またはloaderそれを生成する関数を保護し、ServiceWrapperへのランタイム アクセスまたは への永続的なモックを提供するために拡張するプライベート クラスを定義しますloader。

最初のオプションは、かなり醜い方法でインターフェイスを変更します。ドキュメンテーションによって解決できます (または名前空間によって解決できる可能性があります。その方法についてはよくわかりません)。

2 番目のものは、私が推測するインターフェイスをわずかに保持しますが、テストに大量の追加コードが必要です。

私が見落としている問題に対する解決策や展望はありますか? よろしくお願いします。

4

1 に答える 1

1

最初のオプションは、次の方法です。ローダーをモックします。

作成されたインスタンスが厳密にプライベートのままであり、それらを作成したクラスとのみ対話する場合を除いて、再利用可能なクラス内にオブジェクト作成コードを含めないことを常にお勧めします。これは、外部サービスを使用する場合には当てはまりません。代わりに、ローダーをコンストラクター引数として渡します。そうすれば、ローダーを呼び出したときに、ローダーが作成されていることを確認できます。

オブジェクトの作成は、依存性注入フレームワークを介さない場合は、メインパーティション内で行う必要があります。つまり、新しいアプリごとに書き直す必要があるシステムの部分です。

追加のドキュメントも必要ありません。必要なドキュメントはすべて単体テストにあります。

于 2012-05-16T16:39:29.373 に答える