Sinon: fakeServer ist mit .respond (500) am 1.17.4 defekt

Ich kann bestätigen, dass dies am 1.17.4 geschieht, aber nicht am 1.17.3. Ich habe ein ähnliches Setup mit Karma-Sinon.

Ich vermute, das Problem liegt in diesem Commit https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793

Das Tag 1.17.4 wurde in die npm-Registrierung verschoben, aber ich habe in diesem Repository keine Spur dieses Tags gefunden. Was ist passiert?

Ich vermute, das Tag wurde noch nicht erstellt. Es wurde erst vor 3 Stunden veröffentlicht

@mbarlock Ja, wahrscheinlich - trotzdem denke ich, wäre es besser, wenn das Tag auf GitHub zuerst veröffentlicht würde. Zumindest würden wir einen Blick auf eine PR werfen oder helfen oder etwas zu reparieren.

Mein Fehler. Ich habe git push --tags vergessen. Danke für die Infos zum Bug.

Ich habe gerade bestätigt, dass Commit 2cfbacd definitiv dazu geführt hat, dass die Tests für uns in Mozilla / Loop # 400 fehlgeschlagen sind.

Ich habe den Patch von # 1031 lokal angewendet und er behebt unsere Tests.

Wenn 1.17.4 das vorhandene Verhalten ändert, sollte es nicht Teil einer neuen Hauptversion sein? Derzeit wird es als kompatibel mit 1.17.3 angesehen, sodass eine package.json, die eine Sinon-Abhängigkeit als "^ 1.17.3" angibt, 1.17.4 erhält und möglicherweise Tests fehlschlägt, die früher funktionierten.

Die Funktionsweise von 1.17.3 ist jedoch eine Regression, oder? Fühlen Sie sich frei, mich zu korrigieren. Wenn dies der Fall ist, sollte es repariert und nicht in seinem defekten Zustand gehalten werden.

UPDATE: Dies sieht aus wie ein tatsächlicher Fehler.

Oh, ich hatte Ihre ursprüngliche Diskussion unter https://github.com/sinonjs/sinon/pull/861 @fearphage nicht gelesen. Es scheint, dass dies das richtige Verhalten ist, obwohl ich denke, dass es mehr Auswirkungen haben wird als beabsichtigt, wenn man bedenkt, wie lange der Fehler in der Sinon-Codebasis war.

Angesichts dessen scheint es für mich das Richtige zu sein, meine Tests so zu ändern, dass sie sich auf xhr.onabort anstelle von xhr.onerror verlassen. Ich vermute jedoch, dass diese Änderung für eine Weile zu Verwirrung führen wird, da lokal ausgeführte Komponententests nicht automatisch alle Abhängigkeiten erneut herunterladen, wenn sie in einem node_modules-Verzeichnis vorhanden sind. Daher werden die Benutzer dies herausfinden, wenn sie neue Abhängigkeiten zu ihren hinzufügen package.json (Ich habe es schnell erkannt, weil Travis CI für meine Tests eine npm-Installation von Grund auf neu durchführt).

Ich bin mir nicht sicher, wie ich richtig vorgehen soll. Fügen Sie dem Änderungsprotokoll für 1.17.4 möglicherweise einen Hinweis hinzu, der besagt, dass einige Tests, die auf "onerror" basieren, "onabort" verwenden sollten? (Übrigens enthält http://sinonjs.org/Changelog.txt ab diesem Kommentar noch nicht 1.17.4).

Ich nehme das zurück. Ich habe mich mit der Behebung meiner Tests befasst und festgestellt, dass in https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793 ein neuer Fehler eingeführt wurde. Die Funktion onReadyStateChange löst jetzt ein "Fehler" -ProgressEvent aus, anstatt sich auf die Abbruchfunktion zu verlassen, um onerror direkt aufzurufen, falls definiert. Das Problem ist, dass FakeXMLHttpRequest derzeit keinen Listener für das Ereignis "error" hat.

Ich habe PR https://github.com/sinonjs/sinon/pull/1042 erstellt , um den fehlenden Fehler eventListener-Schlüssel hinzuzufügen. Ohne diese Änderung schlagen alle Komponententests fehl, die prüfen, ob bei einer legitimen Serverfehlerantwort (z. B. 500) eine Fehlerbehandlungsfunktion aufgerufen wird. Lass mich deine Gedanken wissen, @fearphage @ fatso83

Beim ersten Lesen dieses Threads wurde https://github.com/sinonjs/sinon/pull/1041 nicht angezeigt, wodurch der fehlende eventListener-Schlüssel und zusätzlicher Code hinzugefügt werden, um die Reihenfolge der Ereignisse zu bestätigen. Fühlen Sie sich frei, meine PR zu ignorieren, wenn Sie stattdessen damit gehen.

OK, # 1041 (wie # 1042) wurde jetzt zusammengeführt.

@overcaffeinated Bezüglich des fehlenden Änderungsprotokolls, das auf einen Fehler im Build-Skript für die Dokumente zurückzuführen ist, der mich daran gehindert hat, sie zu aktualisieren (siehe https://github.com/sinonjs/sinon/issues/991#issuecomment-216651347). Das tut mir leid. Hoffentlich können wir es wieder zum Laufen bringen und dort einen Hinweis zu der Änderung hinzufügen.

Solche Dinge bringen mich dazu, 2.0 wirklich aus der Tür zu bekommen, damit wir nicht zu viel Energie in die 1.x-Filiale investieren.

1.7.4 hat dazu geführt, dass einige meiner Tests fehlgeschlagen sind. Erwarten wir, dass 1.7.5 dieses Problem löst?

Leider wird es nicht für alle behoben, da # 1031 noch nicht behoben ist. Ich werde versuchen, das heute Abend zu helfen.

Danke für die Info, @ Standard8 !

Ich habe dies aufgrund meiner Interpretation der XHR-Spezifikation behoben (pleite?). Es wäre schön, wenn es eine Browser-Implementierung gäbe, mit der man dies vergleichen könnte, um sicherzustellen, dass es diesmal richtig ist. Wir brauchen ein Testfeld, um die gefälschte xhr-Implementierung von sinon mit der Realität zu vergleichen und sicherzustellen, dass die Ereignisse in der richtigen Reihenfolge ausgelöst werden und die richtigen Ereignisse ausgelöst werden.

Irgendwelche Abnehmer?

@fearphage Irgendeine Idee, wie ein solches

Ich stelle mir vor, es wäre wie browser.cope oder könnte es zumindest als Backend zum Speichern der Ergebnisse verwenden.

Stellen Sie sich jedoch http://www.acidtests.org/ für XHR vor

Hier sind einige anforderungsbasierte Dienstprogramme, die Ihnen helfen sollen:

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

Das scheint eine hervorragende Ressource zu sein! Browserscope ist übrigens ausgefallen.

@fearphage Ich hatte keine Zeit herauszufinden, wie ich etwas in www.browserscope.org einbinden kann , also habe ich stattdessen eine Webseite erstellt:

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

Lädt in den neuesten Versionen von Firefox, Chrome, IE und Safari.

@ Standard8 Ich weiß es zu schätzen. Ich habe dies verwendet, um die gefälschte Serverimplementierung von sinon zu vergleichen. Vielen Dank.

@fearphage @ fatso83 , können Sie bitte einen Überblick über den aktuellen Status dieses Problems geben?

Nach einem kurzen Blick darauf sollten wir in Betracht ziehen, die v1.17.3-Funktionalität zurückzusetzen und eine v1.17.5-Version bereitzustellen. Auch wenn die alte Funktionalität defekt war, stellt dies eine brechende API-Änderung dar und sollte daher in die 2.0-Version übernommen werden.

Ich denke, Sie haben es gut zusammengefasst, obwohl @fearphage mehr auf die Details in diesem master . Ich denke, die meisten Probleme wurden in master behoben, aber ich glaube nicht, dass dies für den Zweig v1.17 gilt (der keine Korrekturen wie # 1031 und # 1041 AFAIK enthält). Ich könnte mich irren (wahrscheinlich).

Ich denke, die pragmatischste Lösung könnte darin bestehen, das zu tun, was Sie gesagt haben:

• Setzen Sie # 1017 (und verwandte?) für den 1.17-Zweig zurück, um das Rauschen zu verringern und die Netzwerk-API gleich zu halten. Versenden Sie eine Version 1.17.5 und akzeptieren Sie einfach, dass die Implementierung weniger korrekt ist als in Version 2
• Behalten Sie die Änderungen in master und dokumentieren Sie einfach, was sich im Migrationshandbuch geändert hat (siehe # 1090).

Ich hole nur nach, was hier los ist. Wäre es besser zu reparieren als zurückzusetzen?

Die größte Veränderung ist, wenn error / onerror abgefeuert wird oder nicht, oder?

@fearphage Danke fürs

Während große Änderungen für eine neue Hauptversion in Ordnung wären, sollte alles, was viele Tests in 1.x zu brechen beginnt, wahrscheinlich zurückgestellt werden, aber ich war mir nicht sicher, ob diese Korrekturen auf master angewendet wurden.

Soweit ich weiß, ist das einzige, was kaputt ist, dass Nicht-200-Anfragen immer noch error Ereignisse auslösen sollten. Gibt es mehr dazu? Ich glaube, alles, was es braucht, sind die Korrekturen vom Master.

Es scheint eine gute Idee zu sein, auch Github und NPM v1.7.4 abzunehmen. Die meisten Leute setzen es zurück oder können nicht darauf aktualisieren.

Wenn sich das alles geändert hat, würde ich vorschlagen, nur die Korrekturen einzubeziehen, die in master eingegangen sind, und so schnell wie möglich eine Version 1.17.5 zu versenden. Könntest du es machen? Ich fahre in den Urlaub ( Date.now() ).

Da das Entfernen von NPM-Versionen nicht als sehr "nett" angesehen wird, habe ich einen Befehl npm deprecate für 1.17.4 ausgegeben. Ich bin mir auch nicht sicher, ob ich das Tag entfernen soll, wenn sich einige Leute darauf verlassen. Dies ist jedoch eine weitere Diskussion, und ich schlage vor, wir konzentrieren uns auf den Versand des Fixes.

Klingt wie ein Plan. Ich sollte dieses Wochenende dazu in der Lage sein.

Ich habe eine vorgeschlagene Lösung für dieses Problem vorgeschlagen, wenn jemand # 1102 abwägen möchte.

Wenn jemand es braucht, habe ich die Testdatei von @ Standard8 ein wenig modifiziert und dies ist das, was ich verwendet habe, um gefälschtes xhr näher an das Browserverhalten heranzuführen.

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

@ Standard8 Nochmals vielen Dank! :klatschen:

Gemäß der Spezifikation wird ein Fehlerereignis nur ausgelöst, wenn ein Ereignis auf Netzwerkebene wie ein DNS-Timeout oder ein nicht reagierender Server auftritt. 500 oder 404 sind nur normale HTTP-Antworten und es liegt an einer Anwendung, zu entscheiden, ob ein Fehler aufgetreten ist. https://www.w3.org/TR/XMLHttpRequest/#event -xhr-error
Die Spezifikation ist wie üblich zu kurz. Nicht-2xx-Antworten werden von jQuery als Fehler angesehen. Aus diesem Grund sind viele Menschen durch das Verhalten von XMLHttpRequest verwirrt.

@ nyk0r : Das ist ziemlich genau das, was Phreds Fix macht :)

@gil : Dies sollte durch die hervorragende Arbeit von @fearphage in # 1102, # 1108 und # 1109 behoben werden. Wenn Ihr Testfall unvollständig ist (keine Überprüfung / Verifizierung), möchten Sie überprüfen, ob er tatsächlich durch den Code in der aktuellen Version 1.17 behoben wurde? In diesem Fall können wir so schnell wie möglich eine neue Patch-Version ausliefern.

Alternativ könnten @wlepinski oder @mbarlock möglicherweise überprüfen, ob dies in der Verzweigung v1.17 behoben wurde. Ändern Sie einfach die Sinon-Abhängigkeit in package.json und lesen Sie: sinon#v1.17 , um den richtigen Zweig direkt von GitHub aus zu verwenden.

OK, durch Ausführen dieses Tests als behoben bestätigt:

"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);
}

Dies funktionierte nicht mit 1.17.4, aber mit den neuesten Korrekturen.

Es stellte sich heraus, dass @fearphage diesen Test bereits in bf709a7f (Zeile 1797) behandelt hat, aber hey ...

Schließen wie fest.

Leider habe ich keinen Zugriff mehr auf dieses Projekt, um es zu testen. Ich arbeite jetzt in einer neuen Firma. Aber ich werde sie wissen lassen, falls sie die Bibliothek aktualisieren möchten. Danke für die Fehlerbehebung!!