Sinon: fakeServer está roto con .respond (500) en 1.17.4

Puedo confirmar que esto sucede en 1.17.4 pero no en 1.17.3. Tengo una configuración similar con karma-sinon.

Supongo que el problema está en este compromiso https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793

La etiqueta 1.17.4 se envió al registro npm pero no encontré ningún rastro de esta etiqueta en este repositorio. ¿Qué sucedió?

Supongo que la etiqueta aún no se ha creado. Solo fue lanzado hace 3 horas.

@mbarlock Sí, probablemente, sin embargo, creo que sería mejor si la etiqueta en GitHub se lanzara primero. Al menos echaríamos un vistazo y ayudaríamos en un PR o algo para arreglar.

Mi error. Olvidé git push --tags . Gracias por la información sobre el error.

Acabo de confirmar que el commit 2cfbacd definitivamente hizo que las pruebas fallaran para nosotros en mozilla / loop # 400.

Apliqué el parche de # 1031 localmente y corrige nuestras pruebas.

Si la 1.17.4 cambia el comportamiento existente, ¿no debería ser parte de una nueva versión importante? Actualmente, se considera compatible con 1.17.3, por lo que un package.json que especifique una dependencia sinon como "^ 1.17.3" obtendrá 1.17.4 y posiblemente fallará las pruebas que solían funcionar.

Sin embargo, la forma en que funciona 1.17.3 es una regresión, ¿verdad? Sientase libre de corregirme. Si ese es el caso, debe arreglarse y no mantenerse en su estado roto.

ACTUALIZACIÓN: Esto parece un error real.

Oh, no había leído tu discusión original en https://github.com/sinonjs/sinon/pull/861 @fearphage . Parece que este es el comportamiento correcto, aunque creo que tendrá más impacto del previsto, dado cuánto tiempo ha estado el error en el código base de Sinon.

Dado eso, parece que lo correcto por mi parte es cambiar mis pruebas para confiar en xhr.onabort en lugar de xhr.onerror. Sin embargo, sospecho que este cambio causará confusión por un tiempo, ya que las pruebas unitarias ejecutadas localmente no vuelven a descargar automáticamente todas las dependencias si están presentes en un directorio node_modules, por lo que la gente se enterará de esto cuando agreguen nuevas dependencias a su package.json (me di cuenta rápidamente porque Travis CI hace una instalación npm desde cero para mis pruebas).

No estoy seguro de cuál es el curso de acción correcto. ¿Quizás agregar una nota al registro de cambios para 1.17.4 especificando que algunas pruebas que se basan en "onerror" deberían usar "onabort"? (por cierto, a partir de este comentario, http://sinonjs.org/Changelog.txt no incluye 1.17.4 todavía).

Tomare eso de vuelta. Busqué corregir mis pruebas y me di cuenta de que se introdujo un nuevo error en https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793 . La función onReadyStateChange ahora desencadena un "error" ProgressEvent en lugar de depender de la función abortar para llamar a un error directamente si está definido. El problema es que FakeXMLHttpRequest actualmente no tiene un oyente para el evento "error".

Creé PR https://github.com/sinonjs/sinon/pull/1042 para agregar la clave de error eventListener que falta. Sin este cambio, cualquier prueba unitaria que verifique si se llama a una función de controlador de error en una respuesta de error de servidor legítima (como 500) fallará. Déjame saber tus pensamientos, @fearphage @ fatso83

En mi lectura inicial de este hilo, no vi https://github.com/sinonjs/sinon/pull/1041 , que agrega la clave eventListener que falta y el código adicional para afirmar el orden de los eventos. Siéntete libre de ignorar mi PR si prefieres eso.

Bien, el # 1041 (igual que el # 1042) ahora se ha fusionado.

@overcaffeinated Con respecto al registro de cambios que falta debido a una falla en el script de compilación de los documentos que me impidió actualizarlos (consulte https://github.com/sinonjs/sinon/issues/991#issuecomment-216651347). Lo siento por eso. Con suerte, podemos hacerlo funcionar nuevamente y agregar una nota sobre el cambio allí.

Cosas como esta me dan muchas ganas de sacar la versión 2.0 para no invertir demasiada energía en la rama 1.x.

1.7.4 hizo que varias de mis pruebas fallaran. ¿Esperamos que 1.7.5 resuelva esto?

Desafortunadamente, no lo solucionará todo el mundo, ya que el número 1031 aún no se ha solucionado. Intentaré ayudarlo esta noche.

¡Gracias por la información, @ Standard8 !

Arreglé (¿rompí?) Esto en función de mi interpretación de la especificación XHR. Sería bueno si hubiera una implementación de navegador con la que comparar esto para asegurarse de que sea correcto esta vez. Necesitamos un banco de pruebas para comparar la implementación falsa de xhr de Sinon con la realidad para asegurarnos de que los eventos se activan en el orden correcto y se activan los eventos correctos.

¿Ningún arrendatario?

@fearphage ¿ alguna idea de cómo se vería un banco de pruebas? un conjunto de pruebas manuales? algo difícil de simular "red inactiva" en navegadores normales. así que no estoy muy seguro de cómo se debe hacer esto.

Me imagino que sería como browserscope.org o al menos podría usarlo como backend para almacenar los resultados.

Sin embargo, imagina http://www.acidtests.org/ para XHR

Aquí hay algunas utilidades basadas en solicitudes para ayudar:

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

¡Parecen recursos excelentes! El buscador está caído, por cierto.

@fearphage No tuve tiempo de averiguar cómo poner algo en www.browserscope.org , así que en su lugar abrí una página web:

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

Se carga en las últimas versiones de Firefox, Chrome, IE y Safari.

@ Standard8 se lo agradezco. He estado usando esto para comparar la implementación del servidor falso de Sinon. Gracias.

@fearphage @ fatso83 , ¿podría proporcionar una descripción general del estado actual de este problema?

De un vistazo rápido, parece que deberíamos considerar revertir la funcionalidad v1.17.3 y proporcionar una versión v1.17.5; incluso aunque la funcionalidad anterior se rompió, esto representa un cambio de API importante y, por lo tanto, ¿debería incluirse en la versión 2.0?

Creo que lo resumiste muy bien, aunque master . Creo que la mayoría de los problemas se han solucionado en master , pero no creo que eso sea válido para la rama v1.17 (que no tiene correcciones como # 1031 y # 1041 AFAIK). Podría estar (probablemente estoy) equivocado.

Creo que la solución más pragmática podría ser hacer lo que dijiste:

• revertir # 1017 (¿y relacionado?) para la rama 1.17 para reducir el ruido y mantener la API de red igual, enviar una versión 1.17.5 y simplemente aceptar que la implementación es menos correcta que en la versión 2
• mantenga los cambios en master y simplemente documente lo que ha cambiado en la guía de migración (consulte el n. ° 1090).

Me estoy poniendo al día con lo que está pasando aquí. ¿Sería mejor arreglar que revertir?

El mayor cambio es cuando error / onerror se despide o no, ¿verdad?

@fearphage ¡ Gracias por participar! Como soy bastante lento, ¿podría hacer un resumen de cinco líneas de los cambios de API que serían evidentes desde la vista de un usuario final existente cuando se hayan aplicado todas las correcciones a la rama v1.17?

Si bien los grandes cambios estarían bien para una nueva versión principal, cualquier cosa que comience a romper muchas pruebas en 1.x probablemente debería estar en espera, pero no estaba seguro de si esas correcciones que se han aplicado a master resolvería la mayoría de los problemas que tiene la gente con 1.17.4.

Por lo que tengo entendido, lo único que no funciona es que las solicitudes que no sean 200 deberían desencadenar eventos error . ¿Hay más en esto? Creo que todo lo que necesita son las correcciones del maestro.

Parece una buena idea extraer v1.7.4 de Github y NPM también. La mayoría de las personas lo están revirtiendo o no pueden actualizarlo.

Si eso es todo lo que ha cambiado, sugeriría simplemente incluir las correcciones que se han incluido en master y enviar una versión 1.17.5 lo antes posible. ¿Lo podrías hacer? Me voy de vacaciones ( Date.now() ).

Como eliminar versiones de NPM no se considera muy "agradable", emití npm deprecate comando

Suena como un plan. Debería poder hacerlo este fin de semana.

Tengo una solución propuesta para este problema si alguien quiere opinar sobre el n. ° 1102.

Si alguien lo necesita, modifiqué un poco el archivo de prueba de @ Standard8 y esto es lo que he estado usando para acercar el xhr falso al comportamiento del navegador.

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

@ Standard8 ¡ Gracias de nuevo! :aplaudir:

De acuerdo con la especificación, el evento de error se activa solo cuando ocurre un evento de nivel de red como un tiempo de espera de DNS o un servidor que no responde. 500 o 404 son solo respuestas HTTP normales y depende de una aplicación decidir si se ha producido un error. https://www.w3.org/TR/XMLHttpRequest/#event -xhr-error
La especificación es demasiado concisa como de costumbre. Las respuestas que no son 2xx son consideradas errores por jQuery, es por eso que muchas personas se confunden con el comportamiento de XMLHttpRequest.

@ nyk0r : eso es más o menos lo que hace la solución de Phred :)

@gil : esto debería ser arreglado por el excelente trabajo de @fearphage en # 1102, # 1108 y # 1109. Como su caso de prueba está incompleto (sin verificación / verificación), ¿le importaría verificar que realmente haya sido arreglado por el código en la rama actual v1.17? Si lo hace, podemos enviar una nueva versión de parche lo antes posible.

Alternativamente, @wlepinski o @mbarlock tal vez podrían verificar que esto se ha solucionado en la rama v1.17 ? Simplemente cambie la dependencia sinon en package.json para leer: sinon#v1.17 para usar la rama derecha directamente desde GitHub.

OK, verificado que se corrigió ejecutando esta prueba:

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

Esto no funcionó con 1.17.4, pero sí con las últimas correcciones.

Resulta que @fearphage ya cubrió esta prueba en bf709a7f (línea 1797), pero bueno ...

Cerrando como fijo.

Desafortunadamente, ya no tengo acceso a ese proyecto para probarlo, ahora estoy trabajando en una nueva empresa. Pero les haré saber, en caso de que quieran actualizar la biblioteca. ¡Gracias por la solución!