¿Cómo se burla del File Picker en el browser para probar la unidad?

Estoy interesado en cómo simular globalmente el selector de files en el browser. Específicamente, estoy más interesado en hacer esto en Firefox, pero preferiría una solución general.

Solo me importa evitar que aparezca el cuadro de dialog del selector de files. No necesito poder afirmar que se haya abierto. El problema es que tengo testings unitarias para el código JavaScript que abre el selector de files. Cuando se abre el cuadro de dialog, detiene la ejecución del set de testings .

Una situación de ejemplo es que estoy probando el método onRender de Backbone.View . Ese método representa una subvista, que abrirá el selector de files cuando se represente. Ya que no estoy probando directamente esa subvista, preferiría no burlarme de partes de su comportamiento cuando solo estoy interesado en probar unidades alguna otra parte del método onRender .

Ejemplo:

 //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 } 

Básicamente, no quiero burlar explícitamente el comportamiento que hace que se abra el selector de files porque no es lo que estoy interesado en probar aquí. Hacerlo hará que el banco de testings sea mucho más frágil y difícil de mantener.

Use sinon para burlarse / espiar / anular las llamadas. Puede probar las llamadas que se realizan en lugar de realizar las llamadas.

De esta forma, puede probar que se ha llamado a la function sin llamar a la function real que muestra el cuadro de dialog.

Para responder a tu pregunta: simplemente no lo hagas.

Reemplazaría a subview.render() con una function vacía para evitar el efecto secundario no deseado. Usted dice sin embargo:

"No quiero burlar explícitamente el comportamiento que hace que se abra el selector de files porque no es lo que me interesa probar …"

Lo cual es un poco contradictorio. Si desea probar la unidad de App.Views.SomeView , deberá burlarse de los queueboradores externos, especialmente cuando no sea interesante, e include el selector de files. Por otro lado, no deberías meterse con el SUT cuando lo pruebes por unidad.

Burlarse de hecho haría que tu testing sea más propensa a ser roja , pero es la única manera de asegurarte de que tu código de producción no sufra forms de acoplamiento incorrectas (en mi humilde opinión, una trampa común con las aplicaciones de Backbone.js).

El único lugar en el que necesitaría evitar que se muestre el selector de files, es cuando realice una testing unitaria de su selector de files, en ese caso podría usar sinon como se sugiere o dejarlo sin cobertura si está usando jQuery. Recuerde la regla "Nunca se burle de un tipo que no le pertenece" .