Come si prende in giro il File Picker nel browser per il test dell'unità?

Question

Sono interessato a come a livello globale prendere in giro il selettore di file nel browser. In particolare, sono più interessato a farlo in Firefox ma preferirei una soluzione generale.

Mi interessa solo impedire la visualizzazione della finestra di selezione del file. Non ho bisogno di essere in grado di affermare che è stato aperto. Il problema è che ho dei test unitari per il codice JavaScript che aprono il selettore di file. Quando si apre la finestra di dialogo, interrompe l'esecuzione della suite di test.

Una situazione di esempio è che sto testando il metodo onRender di Backbone.View. Questo metodo esegue il rendering di una sottoview, che aprirà il selettore di file al momento del rendering. Dal momento che non sto testando direttamente questa sottoview, preferirei non deridere porzioni del suo comportamento quando sono interessato solo a testare unitamente un'altra parte del metodo onRender.

Esempio:

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

In sostanza, non voglio prendere in giro in modo esplicito il comportamento che provoca il selettore file per essere aperto perché non è ciò che mi interessa in fase di test qui. Ciò renderà la suite di test molto più fragile e difficile da mantenere.

Answer 1

Utilizzare sinon per simulare/spia/arrestare le chiamate. È possibile verificare le chiamate effettuate anziché effettuare effettivamente le chiamate.

In questo modo è possibile verificare che la funzione sia stata chiamata senza chiamare la funzione effettiva che visualizza la finestra di dialogo.

Answer 2

Per rispondere alla tua domanda: Semplicemente no.

Sostituire subview.render() con una funzione vuota per evitare l'effetto collaterale indesiderato. Tu dici però:

"Io non voglio prendere in giro in modo esplicito il comportamento che provoca il selettore file da aprire perché è non quello che sono interessati a testare ..."

Che è un po 'contraddittorio. Se si desidera Unit-Test App.Views.SomeView, si devono prendere in giro collaboratori esterni, in particolare quando non sono interessanti e incluso il selettore di file. D'altra parte, non dovresti scherzare con lo SUT durante il test dell'unità.

Mocking sarebbe infatti rendere il test più inclini ad essere rosso, ma è l'unico modo per assicurarsi che il codice di produzione non soffre di forme malati di accoppiamento (IMHO, Un errore comune con le applicazioni Backbone.js.)

L'unico posto in cui è necessario evitare il selettore di file da visualizzare, è quando testare l'unità il selezionatore di file stesso, in tal caso è possibile utilizzare sinon come suggerito o lasciarlo senza copertura se si è usando jQuery. Ricordare il "Non deridere mai un tipo che non possiedi" la regola.