Sinon: fakeServerは1.17.4で.respond（500）で壊れています

これは1.17.4で発生しますが、1.17.3では発生しないことを確認できます。 私はカルマシノンと同様の設定をしています。

私の推測では、問題はこのコミットにありますhttps://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793

タグ1.17.4はnpmレジストリにプッシュされましたが、このリポジトリでこのタグの痕跡は見つかりませんでした。 何が起こった？

私の推測では、タグはまだ作成されていません。 3時間前にリリースされただけです

@mbarlockええ、おそらく—それでも、GitHubのタグが最初にリリースされた方がいいと思います。 少なくとも、PRや修正するものを調べて支援します。

私の悪い。 git push --tags忘れました。 バグに関する情報をありがとう。

commit 2cfbacdが原因で、mozilla / loop＃400のテストが確実に失敗することを確認しました。

＃1031のパッチをローカルに適用すると、テストが修正されます。

1.17.4が既存の動作を変更する場合、それは新しいメジャーリリースの一部であるべきではありませんか？ 現在、1.17.3との互換性があると見なされているため、sinon依存関係を「^ 1.17.3」として指定するpackage.jsonは1.17.4を取得し、以前は機能していたテストに失敗する可能性があります。

1.17.3の動作はリグレッションですよね？ お気軽に訂正してください。 その場合は、修正して、壊れた状態に維持しないでください。

更新：これは実際のバグのようです。

ああ、 https： //github.com/sinonjs/sinon/pull/861@fearphageであなたの元のディスカッションを読んでいません

それを考えると、私の側で行うべき正しいことは、xhr.onerrorではなくxhr.onabortに依存するようにテストを変更することであるように見えます。 ローカルで実行される単体テストは、node_modulesディレクトリに存在する場合、すべての依存関係を自動的に再ダウンロードしないため、この変更によってしばらく混乱が生じると思われます。そのため、新しい依存関係を追加すると、このことを知ることができます。 package.json（Travis CIはテスト用にnpmインストールを最初から行うため、すぐに気付きました）。

正しい行動方針が何であるかわかりません。 たぶん、1.17.4の変更ログに、「onerror」に依存する一部のテストで「onabort」を使用するように指定するメモを追加しますか？ （ところで、このコメントの時点で、http：//sinonjs.org/Changelog.txtにはまだ1.17.4が含まれていません）。

私はそれを取り戻します。 テストの修正を調べたところ、 https：//github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793に新しいバグが導入されていることが

欠落しているエラーeventListenerキーを追加するために、PRhttps ：//github.com/sinonjs/sinon/pull/1042を作成しました。 この変更がないと、正当なサーバーエラー応答（500など）で呼び出されているonerrorハンドラー関数をチェックする単体テストは失敗します。 @fearphage @ fatso83 、あなたの考えを教えてください

このスレッドを最初に読んだときに、 https：//github.com/sinonjs/sinon/pull/1041が表示されませんでした

OK、＃1041（＃1042と同じ）がにマージされました。

@overcaffeinatedドキュメントのビルドスクリプトの失敗が原因で変更ログが欠落しているため、ドキュメントを更新できませんでした（https://github.com/sinonjs/sinon/issues/991#issuecomment-216651347を参照）。 申し訳ありません。 うまくいけば、それを再び機能させて、そこに変更についてのメモを追加することができます。

このようなものは、1.xブランチにあまり多くのエネルギーを投資しないように、2.0をドアから出したいと本当に思っています。

1.7.4により、いくつかのテストが失敗しました。 1.7.5でこれを解決できると思いますか？

残念ながら、＃1031はまだ修正されていないため、すべての人に修正されるわけではありません。 私は今晩それを助けようとします。

情報をありがとう、 @ Standard8 ！

XHR仕様の解釈に基づいて、これを修正（壊れましたか？）しました。 今回はこれが正しいことを確認するためにこれを比較するブラウザの実装があればいいのにと思います。 シノンの偽のxhr実装を実際と比較して、イベントが正しい順序で発生し、正しいイベントが発生することを確認するためのテストベッドが必要です。

テイカーはいますか？

@fearphageそのようなテストベッドがどのように見えるかについて何か考えはありますか？ 一連の手動テスト？ 通常のブラウザで「ネットワークダウン」をシミュレートするのは難しいです。 だから私はこれがどのように行われるべきか本当にわかりません。

browserscope.orgのようなものか、少なくとも結果を保存するためのバックエンドとして使用できると思います。

XHRのhttp://www.acidtests.org/を想像してみて

役立つリクエストベースのユーティリティは次のとおりです。

https://httpbin.org/
http://requestb.in/

それは素晴らしいリソースのようです！ ところで、Browserscopeはダウンしています。

@fearphage www.browserscope.orgに何かを取り込む方法を

http://people.mozilla.org/~mbanner2/sinonXHRBrowserTest.html

Firefox、Chrome、IE、Safariの最新バージョンをロードします。

@ Standard8ありがとうございます。 私はこれを使用して、sinonの偽のサーバー実装を比較してきました。 ありがとうございました。

@fearphage @ fatso83 、この問題の現在の状況の概要を教えてください。

簡単に説明すると、v1.17.3の機能を元に戻し、v1.17.5のリリースを提供することを検討する必要があるようです。古い機能が壊れていたとしても、これはAPIの変更が壊れていることを示しているため、2.0リリースに組み込む必要がありますか？

@fearphageはこれについての詳細に詳しくありmasterものを頭に抱えようとすると、私は圧倒され続けます。 ほとんどの問題はmasterで修正されたと思いますが、v1.17ブランチ（＃1031や＃1041 AFAIKなどの修正はありません）には当てはまらないと思います。 私は（おそらく）間違っているかもしれません。

私はあなたが言ったように最も実用的な解決策はそうすることかもしれないと思います：

• 1.17ブランチの＃1017（および関連する？）を元に戻して、ノイズを下げ、ネットワークAPIを同じに保ち、1.17.5リリースを出荷し、バージョン2よりも実装が正しくないことを受け入れます。
• 変更をmasterし、移行ガイドで変更内容を文書化するだけです（＃1090を参照）。

私はここで起こっていることに追いついているところです。 元に戻すよりも修正する方が良いでしょうか？

最大の変化は、 error / onerrorが解雇されるかどうかですよね？

@fearphageチャイムをしてくれてありがとう！ 私はかなり遅いので、すべての修正がv1.17ブランチに適用されたときに、既存のエンドユーザーの観点からどのAPIの変更が明らかになるかについて5行の要約を作成していただけますか？

新しいメジャーバージョンでは大きな変更は問題ありませんが、1.xで多くのテストに違反し始めたものはおそらく保留になっているはずですが、 master適用された修正があるかどうかはわかりません

私が理解している限り、壊れているのは200以外のリクエストがerrorイベントをトリガーすることだけです。 これにはもっとありますか？ 必要なのはマスターからの修正だけだと思います。

GithubとNPMからもv1.7.4を取得するのは良い考えのようです。 ほとんどの人はそれを元に戻しているか、アップグレードできません。

それがすべて変更された場合は、 master入った修正を含めて、1.17.5リリースをできるだけ早く出荷することをお勧めします。 できますか？ 私は休暇で出かけます（ Date.now() ）。

NPMバージョンの削除はあまり「良い」とは見なされないため、1.17.4に対してnpm deprecateコマンドを発行しました。 一部の人々がタグに依存している場合は、タグを削除することについてもわかりません。 ただし、これは別の議論であり、修正の出荷に焦点を当てることをお勧めします。

計画のようだ。 私は今週末にそれを得ることができるはずです。

誰かが＃1102を検討したい場合は、この問題の修正案を提案します。

誰かがそれを必要とするなら、私は@ Standard8のテストファイルを少し修正しました、そしてこれは私が偽のxhrをブラウザの振る舞いに近づけるために使ってきたものです。

https://dl.dropboxusercontent.com/u/2400/tc/sinon/xhr-browser-test.htm

@ Standard8ありがとうございました！ ：拍手：

仕様によると、onerrorイベントは、DNSタイムアウトや応答しないサーバーなどのネットワークレベルのイベントが発生した場合にのみトリガーされます。 500または404は通常のHTTP応答であり、エラーが発生したかどうかを判断するのはアプリケーション次第です。 https://www.w3.org/TR/XMLHttpRequest/#event -xhr-error
スペックはいつものように簡潔すぎます。 2xx以外の応答は、jQueryによってエラーと見なされます。そのため、多くの人がXMLHttpRequestの動作に混乱しています。

@ nyk0r ：それはPhredの修正が行うこととほとんど同じです:)

@gil ：これは、＃1102、＃1108、および＃1109での@fearphageの優れた作業によって修正されるはずです。 テストケースが不完全であるため（チェック/検証なし）、現在のv1.17ブランチのコードによって実際に修正されていることを確認しますか？ その場合、新しいパッチリリースをできるだけ早く出荷できます。

あるいは、 @ wlepinskiまたは@mbarlockは、これがv1.17ブランチで修正されたことを確認できますか？ package.jsonのsinon依存関係を次のように変更するだけです： sinon#v1.17は、GitHubから直接適切なブランチを使用します。

OK、次のテストを実行して修正されることを確認しました。

"call load handler on non-2xx statuses" : function(){
  var stub = sinon.stub();
  this.xhr.addEventListener("load", stub);
  this.xhr.open("GET", "/");
  this.xhr.send();

  this.xhr.respond(500, { 'Content-Type' : 'application/json' }, JSON.stringify({}));
  assert(stub.called);
}

これは1.17.4では機能しませんでしたが、最新の修正では機能します。

@fearphageはすでにbf709a7f（1797行目）でこのテストをカバーしていることが

修正されたとおりに終了します。

残念ながら、私はもうそのプロジェクトにアクセスしてテストすることができません。現在、新しい会社で働いています。 ただし、ライブラリを更新したい場合に備えて、お知らせします。 修正してくれてありがとう！