ember.js - La actualización de Ember rompe una prueba, y solo en Safari

ember-qunit

Question

Estoy tratando de atrapar un Heisenbug .

Estoy actualizando nuestro proyecto de Ember CLI 0.2.0 y Ember 1.10.0 a Ember CLI 0.2.3 y Ember 1.11.1. Este ha sido un proceso bastante libre de dolor, pero tengo exactamente una prueba que ahora solo falla en Safari (7.1.5). Pasa en PhantomJS, Chrome y Firefox.

Es molesto que la prueba solo falle cuando Testem inicia la ejecución de prueba (es decir, cuando un cambio en el código desencadena una ejecución de prueba de actualización automática). Si inicio las pruebas desde dentro de la interfaz web de Qunit, pasa. Ambas cosas son ciertas independientemente de la agrupación de prueba. La característica que se prueba funciona muy bien cuando se ejecuta manualmente en el navegador.

Es una prueba de integración y verifica que cuando se cambia un valor en una entrada, la entrada se actualiza con el valor devuelto por el servidor. En las pruebas, el "servidor" es una instancia de Pretender. Así es como se ve la prueba en sí:

test(''Editing allocation cell'', function() {
  visit(''/district/periods'');

  fillIn(SELECTORS.definitionRowInput(1,0), ''100'');
  triggerEvent(SELECTORS.definitionRowInput(1,0), ''focusout'');
  // The triggerEvent should be tripping the focusOut event on a particular
  // Ember.Textfield subclass, which subsequently leads to a POST request to
  // the server. On Safari, however, the focusOut event isn''t being called here.
  // It is called elsewhere in the app, and it works in production.
  // Things that also don''t work: keyEvent(element, ''keypress'', 16) (a tab), 
  // sending ''blur'', sending ''focus-out''.
  // ''focus-out'' also fails in Firefox, ''blur'' and tab fail in all 4 envs

  andThen(function() {
    equal($(SELECTORS.definitionRowInput(1,0)).val(), ''90'', ''The updated input takes the return value from the server (even if it is different from input)'');
    equal($(SELECTORS.gradeTotal(2)).text(), ''120'', ''Grade total updates with the new sum'');
  });
});

Tenga en cuenta el segundo y andThen() bloque andThen() : al enviar el focusout al control, deberíamos solicitar un código en el componente de respaldo para actualizar los datos al servidor. Los otros navegadores hacen esto: puse console.log() en el respondedor de Pretender para verificarlo, pero Safari no lo hace. Supongo que no responde correctamente al evento de focusout .

Teniendo en cuenta que esta prueba pasa en una rama que solo se diferencia por la actualización CLI de Ember ... ¿qué es probable que haya cambiado para hacer que esto se rompa?

ETA: He revertido de forma individual todas las bibliotecas actualizadas en esta actualización y la prueba continúa fallando. El único cambio que parece funcionar es deshacerse de Ember. Se rompe en 1.11.0 de la misma manera que en 1.11.1, por lo que el cambio está entre 1.10.0 y 1.11.0. (Eso solo me deja ~ 600 commits para pasar por ...)

ETA2: reduje el alcance a entre 1.11.0-beta.5 y 1.11.0. Intento usar bower link para usar construcciones locales de ascua pero las compilaciones de ascua no han sido fiables hasta el momento al ejecutar las pruebas, y la relación de esas dos etiquetas no es una que conduzca a una bisección efectiva.

Answer 1

No puedo ayudarte con tus pruebas en realidad, pero acortar la historia no es tan difícil. Hay 49 parches entre las etiquetas que mencionas. Una secuencia de comandos de git cherry-pick da la rama que cargué en https://github.com/rdebath/test/tree/ember.js

Cada una de las confirmaciones en esa rama (después de la etiqueta v1.11.0-beta.5) proviene de una ''buena'' ruta entre las etiquetas que mencionaste. Los hashes de confirmación son todos diferentes (obviamente) pero el hash de árbol final es el mismo que v1.11.0, así que esta debería ser una buena ruta para git bisect.

Los problemas de compilación también se pueden evitar, por ejemplo, sugiero usar una bisección para encontrar el parche que los causa y git rebase -i ese parche lo más tarde posible. Eso debería poner un problema justo al lado de su solución; pero probablemente no sea una buena idea "aplastar" esos compromisos, ya que quiere poder relacionar todo de nuevo con el árbol real.

Para ayudar a elegir la lista de confirmaciones, utilicé el comando:

git log --graph --decorate --oneline --date-order --all

Con eso, el camino "agradable" es razonablemente obvio.