Test dell'unità Javascript - mock o fixture?

3

Interessato a qualche opzione ...

Sto introducendo i test unitari di JS in un team, testeremo in gran parte i moduli con molte interazioni dom e aggiornamenti.

Tradizionalmente ho sempre usato mock e spys quando testavo librerie come jquery, ma dato che questa è una squadra nuova ai test unitari ho pensato che i dispositivi possano aiutarli a diventare più veloci.

Alcune delle preoccupazioni che ho riguardo all'uso dei dispositivi sono:

  • I test potrebbero diventare più simili ai test di integrazione, che abbiamo già
  • Perdere il vantaggio di un codice scritto, strutturato, astratto e astratto che il testing dell'unità incoraggia.
  • Le fixture rallenteranno la velocità dei test
  • La manutenzione dei proiettori potrebbe diventare un overhead nascosto.

Ma è davvero interessato ad ascoltare le opinioni degli altri.

Grazie in anticipo

    
posta user3453133 23.06.2015 - 14:14
fonte

1 risposta

3

In effetti, tali dispositivi non sono un buon modo per eseguire i test unitari. L'obiettivo dei test unitari è quello di testare una parte molto specifica (e spesso molto piccola) del codice in isolamento dal codice rimanente e dall'ambiente. Rendendo questi test basati sullo stato particolare della pagina web, perdi l'aspetto "unitario" dei tuoi test, il che significa che preferirai invece test di sistema e di integrazione.

Hai anche ragione sull'aspetto della velocità dei test. Il DOM è noto per essere terribilmente lento, quindi se i tuoi test si basano molto sul DOM, non aspettarti di eseguirne migliaia in un secondo.

Hai anche ragione nel sostenere che la manutenzione dei proiettori può essere un compito difficile. In sostanza, se la struttura HTML della tua applicazione web cambia, devi rifletterci su ogni possibile dispositivo. Se i dispositivi vengono scritti a mano, perderai un sacco di tempo per farlo. Se i proiettori sono generati, potresti perdere un sacco di tempo per sintonizzare il generatore stesso.

Il vantaggio del tuo approccio diventa evidente quando la scelta è tra testare almeno qualcosa o non testare nulla. Se il progetto è sotto pressione, i dispositivi possono essere una buona scelta per introdurre il tuo team ai test automatici.

  • Se il progetto è abbastanza piccolo, tali test potrebbero essere l'unica cosa di cui hai bisogno: aggiungere test unitari non porterà troppo a lungo termine e avrà un impatto sul progetto a breve termine.

  • Se il progetto è di grandi dimensioni ma non c'è tempo per sviluppare una suite completa di test unitari, inizia con il test del sistema con i dispositivi. Una volta che hai una copertura di filiali sufficiente, puoi concentrarti sul nuovo codice, codice con la minore copertura e codice con la maggior parte dei bug per aggiungere test di unità, classe per classe.

Un vantaggio importante è che se il tuo codice base non è ben progettato per i test unitari, aggiungerli ora richiederà il refactoring, che a sua volta potrebbe generare regressioni. Se hai già abbastanza test di sistema usando le fixture, il tuo team potrebbe essere più a suo agio nel rifattorizzare quando aggiungi i test unitari in seguito, sapendo che hanno test di sistema per rilevare almeno alcune regressioni.

    
risposta data 23.06.2015 - 14:46
fonte

Leggi altre domande sui tag