6

ブラウザでファイルピッカーをグローバルにモックアウトする方法に興味があります。具体的には、Firefoxでこれを行うことに最も関心がありますが、一般的な解決策を好みます。

ファイルピッカーダイアログが表示されないようにすることだけに関心があります。開いたと断言できる必要はありません。問題は、ファイル ピッカーを開く JavaScript コードの単体テストがあることです。ダイアログが開くと、テスト スイートの実行が停止します。

例の状況は、私がonRendera のメソッドをテストしていることですBackbone.View。このメソッドはサブビューをレンダリングし、レンダリング時にファイル ピッカーを開きます。私はそのサブビューを直接テストしていないので、onRenderメソッドの他の部分の単体テストのみに関心がある場合は、その動作の一部をモックアウトしないことをお勧めします。

例：

//Test file
it("should do something", function() {
  var view = new App.Views.SomeView();
  spyOn(view.modelBinder, "bind");
  view.render();
  expect(view.modelBinder.bind).toHaveBeenCalled();
});

//View file
onRender : function () {
  this.modelBinder.bind(this.el, this.model);
  this.$("#thing").html(this.subview.render().el); //This line has a side effect that opens file picker
}

基本的に、ファイル ピッカーが開かれる原因となる動作を明示的に模倣したくはありません。これは、ここでテストする対象ではないためです。これを行うと、テスト スイートがより脆弱になり、保守が困難になります。

4

2 に答える 2

1

sinonを使用して、呼び出しをモック/スパイ/スタブします。実際に呼び出しを行う代わりに、行われる呼び出しをテストできます。

そうすれば、ダイアログを表示する実際の関数を呼び出さずに、関数が呼び出されたことをテストできます。

于 2012-11-20T20:19:23.467 に答える
0

あなたの質問に答えるには：そうしないでください。

subview.render()望ましくない副作用を避けるために、空の関数に置き換えます。ただし、次のように言います。

「ファイルピッカーが開かれる原因となる動作を明示的にモックアウトしたくありません。これは私がテストしたいものではないためです...」

これは少し矛盾しています。Unit-TestApp.Views.SomeViewが必要な場合は、外部の共同作業者をモック アウトする必要があります。特に興味がない場合は、ファイル ピッカーを含める必要があります。一方、単体テストを行う場合は、 SUTをいじってはいけません。

実際、モッキングはテストを赤くする傾向がありますが、実稼働コードが不適切な形式の結合に悩まされないようにする唯一の方法です (私見、Backbone.js アプリの一般的な落とし穴)。

ファイル ピッカーの表示を避ける必要がある唯一の場所は、ファイル ピッカー自体の単体テストを行う場合です。その場合、sinon を推奨どおりに使用するか、jQuery を使用している場合はカバレッジなしでそのままにしておくことができます。「所有していない型を決してモックしない」というルールを覚えておいてください。

于 2013-01-08T18:52:40.540 に答える